1

We have an internal nuget package that wraps up the IConfiguration+ConfigurationBuilder for various .net core console/service apps (TL;DR, because people got creative), and it has a dictionary property for the common sections we use. AppSettings (for backward compatibility), ConnectionStrings, and ServiceEndpoints. If the need arises, I can add methods to return any type of object (no one has requested yet, we try to keep configs dead simple)

ex. var myDatabaseConnectionString = ConfigurationManager.ConnectionStrings["MyDatabase"];

Code review for someone who updated a .net framework app to .net core and they wrote their own IConfiguration wrapper for accessing the appsettings.json file, so I pointed out that we already had a library for that.
In the reply, he said he couldn't use our library because it had an 'AppSettings' property and since his appsettings.json file didn't have that section, he didn't want to cause a runtime exception.

OK, WTF...I even sent him a link to the documentation (includes explaining the backward compatibility part)...why the frack would you think because a property exists and you don't use it, that would cause some kind of runtime exception?
We have dozens of .net framework apps migrated to .net core with zero code changes and no one ever brought this up as a concern (because, why would they?)

Deep breath...ahhh...I respond that not having an AppSettings section in the appsettings.json file won't cause an exception, if you don't have one, don't need it, you don't have to use it.

He went ahead merged+committed his code anyway with his own IConfiguration+ConfigurationBuilder plumbing.

Code addiction is real kids...it's real.

Comments
  • 1
    That’s not code addiction. It depends but trying to avoid unnecessary dependencies, especially if they provide no substantial value, is a good practice.

    From his perspective, he can’t be sure that it won’t cause a runtime exception. Because the dependency might just call that property by itself.
  • 1
    @Lensflare > "It depends but trying to avoid unnecessary dependencies"

    Agree 100%. Keep things simple.

    It's all 'open source' around here, he knows it won't cause a problem.

    It almost falls into the camp of genius that when they see what's going on 'under the hood', copy the behavior and brag how you decreased the dependency/complexity.

    Ex. Once had a dev that wrote his own parallel for-each library because he found a concurrency 'bug' when he reversed engineered the MS code base (this was before MS open sourced everything). Really low level .net thread stuff he figured out, and it worked (we didn't encounter the bug), but the bug was eventually fixed and his library had a bigger bug he blamed on how the devs were using his library. We stopped using his lib.

    If you're curious, the bug was if you searched for product X on our site, you would sometimes see product Y, searched by another customer.
Add Comment