0

I am working on removing obsolete/unused pieces of configuration from a .NET product starting with appSettings. There are multiple solutions and I've noticed that appSettings can be in a .config file in one project but which are somehow read in another project, sometimes in a separate solutions.

What I'm trying to figure out:

  • How to tell from which .config file a particular configuration setting is read?
  • How to tell which configuration settings can be removed?

Some easy cases:

  • there is an appSetting with a key like 'ResetHelloWorldWhenFooBarHappens'. I can full text search all solutions and it only appears in the app.config file I'm cleaning up. It can be removed.
  • there is an appSetting which Visual Studio Ctrl + F (search document/project/solution) shows me is used everywhere and is holding the project together. It can be removed but the application will fail.
  • there is an appsetting which is not used anywhere in the solution but the key name is included in an enum in a separate solution named Shared which handles logging for several solutions. I can remove it and see that logging stops working for that solution.

Some tricky cases:

  • there is an appSetting in a config file which is not being used in that project but it is used in a different project which does not have it's own config files. I can look at the project references (or dependencies if its a newer SDK style project), see there is some kind of connection between the projects and guess that the appSettings is being used.
  • there is an appSetting with a generic name like 'path' which appears in various other config files and is read/gotten in obscure code by various projects and solutions. I don't know what to do. I could leave all of those appSettings alone even if most of them do nothing. If I remove some/all of them it's difficult to figure what has changed or if anything has broken.

Thanks in advance.

Astrophe
  • 113

1 Answers1

2

The right approach is probably to refactor the code first and encapsulate all "appSettings" access in a central place in each project. This is specificially true for the "obscure" code, as you described it, which accesses the appsettings of other applications. The central config classes or components should provide an API which does not allow passing strings as config item keys, all key strings should be strictly kept in the capsule.

Then, identifying the unused parts of the configuration files should become a lot easier, since now one can restrict the analysis to a rather small part of the code base.

Of course, refactoring requires a certain testing effort, and I guess you were looking for a simpler solution. However, take my word for it: I fear there is none. Once a code base makes access to global resources like configuration files in arbitrary, unrestricted ways, it has become an almost unmaintainable mess. The only way to deal with this is to bite the bullet, rework the technical debt and clean the mess up.

Doc Brown
  • 218,378