CODEWITHSUNDEEP
.netweb-configapp-config
Jerad Rose
Jerad Rose

Reputation: 15503

Sharing config files & database connection strings across enterprise

Our company has several applications -- both web and console/windows -- that all connect to the same set of databases. I'm trying to figure out the best way to store/access/manage the various database connection strings so that they can be shared across all of the applications.

Currently, we have our connection strings in machine.config files on all of our servers. While this eliminates the need to have these connection strings in each application's config file, we still have to have the same block of settings on each server, and each server has 4 different versions we have to include these in (32-/64-bit, 2.0 and 4.0 frameworks). Additionally, each server has its own environment (dev, QA, production), so these settings have to be kept separate. This adds up, and becomes hard to manage when changes are needed.

Ideally, it would be nice to have a central location on each server -- maybe shared on a network -- where these database connection strings (and possibly other info) are stored. I've looked into a few options, but each of them has limitations:

configSource and appSettings file

This seems nice, but only works at the app.config and web.config level, and does not support absolute (or UNC) paths. If we could get this to point to a central location on the server, then this may work. But as I understand it, it must live in a location below the application root, and must be a relative path. I read about using a file link, and this would work if we deployed each app after a change, but we don't want to have to do that -- we want to be able to deploy the file to one location (per server, worst case) and be done.

linkedConfiguration

In theory, this sounds like what we want. But I'm finding very little support for it, so am wondering if this has been deprecated, doesn't work as I'm thinking, or isn't recommended.

How do others go about sharing configuration values like this, and is there a way to use any of the methods above to do what I described? What are best practices for our situation?

Thanks in advance.

Upvotes: 2

Views: 657

Answers (2)

Sid
Sid

Reputation: 81

Hope this helps, though it might exactly not be the same as the question asked.

To manage configurations across various environments, we used a very good approach that utilized build automation tools like maven and Jenkins, and a simple java program along with some bash scripting.

We created a Dictionary that contained various properties for all environments(DEV, QA, PROD), it was to be applied on a general template that contained a list of configuration files for all environments, the Java program replaced placeholders in the template, with the values in the dictionary, to create configuration files for all the environments, so all the configurations are now managed at code level from the dictionary we created. the Java Program was executed inside of a maven build, which would also copy any other resource that we might need in the produced configuration files(such as certificates), the whole thing was packaged and deployed in the server through Jenkins, where in the last part the bash scripts would place the configuration files in the right folder, thus automating everything.

Upvotes: 0

granadaCoder
granadaCoder

Reputation: 27842

Based on this post, this isn't possible.

http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1cad3740-12f5-4859-ba02-717c4b418a8c/

It must refer to a file in the same directory or in a subdirectory as the configuration file.

Now, if you want to research a "tractor trailer" version of configuration, go down this rabbit hole:

http://msdn.microsoft.com/en-US/vstudio/bb499684.aspx

Configuration Service

or (same thing, but a different way to look for it) google or bing this

stocktrader msdn "Configuration Service"

It's not for the mild hearted. But is all about deploying configuration changes to large environments.

Upvotes: 1

Related Questions