1

From the .Net perspective (C#, VB, etc.) and MSSQL, I have noticed that for a set of applications (maintained by the same development team) typically have the same defined configuration for connecting to the database.

<DbConnection Name="SomeConnection" UserId="SomeUser" Key="SomeKey" ConnectionTemplate="server=SomeServer;Initial Catalog=..."/>

For my question, should these applications with pretty much identical configurations have a single consolidated area to retrieve this data instead of the application specific web.config/ConfigurationManager? (consolidated area could be files in a shared folder or some configuration-esque database lookup tables)

One of the practices that feels like there is a benefit for consolidation is Password Manager/Vault, where the User Id and Key are submitted to retrieve the actual password for the service account. During the lifetime of the applications, the Password Manager/Vault could change as upgrades to existing software or "new/better" software are made (my current scenario). This is assuming that the proper channels agree and make the necessary changes for the swap. (swap meaning the company-wide installation and ability request accounts/keys/passwords to be added are complete and available)

For maintenance from the development team standpoint, we are looking to keep things simple to be more flexible as work requests are provided, but a request to swap Password Managers/Vaults can be cumbersome. The difficulty/amount of time needed depends on security team(s) for processing request for intended new items (new service account, access to endpoints, etc.)

Since this item primarily impacts connection strings, the idea of consolidating these configuration items was tossed around. This consolidation would involve the "old" and "new" formats, where some application setting would be updated when the swap is ready to be implemented.

Some development work has been started on the idea, but I am concerned about any gotchas or smells that may not be apparent in the first few passes. I do not know if discussing the specifics on the draft implementation would be helpful for the question, but I can go into those specifics if needed.

Improve this question
2

You can't know every use case for your component ahead of time. So if you pull the config into a common component, can you test it thoroughly? Don't forget to comment your abstractions.

Another consideration is the knowledge level of the programmers who will come after you to maintain the software. Will they know to use the component instead of just writing their own connection string (and other configured items) if they were to create a new config file? Is there a template they can use and you can modify?

What about applying connection string or other configuration to just the exact use case you intend? Is there a chance that the config will need to be different in one or a few cases?

That said, I fully support abstracting or writing a wrapper around your Password Manager/Vault and using an interface to access it. Especially if you foresee a case where you would upgrade or swap to a new Vault in the future.

What other gotchas do you foresee?

Improve this answer
3
  • For testing, we have options that can be implemented with the current proof of concept. The POC is a class library referenced as a DLL by the other apps, and that code has its own config file. The main gotchas that I see deal with maintenance over time, but I wonder if I am missing gotchas with developing new code or apps. To avoid confusion, a clean up of connection strings would be done (each app won't need copies of connection strings). For modifications/new templates, we are looking to have a configuration database, so the tables would act as templates and could be easily modified. – eparham7861 Dec 28 '19 at 3:39
  • Yes. Config can be a source of hard-to-find bugs. I am finding your carefulness refreshing! Anything you can do to make obvious what is stored in your config database, what conditions would require changes and who can make changes, and what the various config items are used for is all to the good. I worry about uninformed programmers going off and writing new config because it's difficult to learn about what already exists. Make it as easy as possible to learn, with lots of examples and comments. – rjacobsen0 Dec 28 '19 at 22:48
  • As an aside for new programmers/team members, the team has discussed the potential of a more formalized onboarding, since we have run into varying degrees of this situation (Dev maintained items with moderate to high change frequency with no context of the why or how the item was setup). Outside of new programmers, new work, or documentation, if you inherited some single or set of apps setup with this config wrapper format, would there be any other blatant red flags? – eparham7861 Dec 30 '19 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.