1

I have found that in the Machine.config you can add your connection strings so that you don't need your connection strings in each running apps config file. The down side to this is that you have number of framework versions * 2 machine.config file. So for version 4.* you have 2 alone. This took my research on to find that you can externalize the connection string using the configSource attribute in the connectionString element of the machine.config

<connectionStrings configSource="Config\connectionStrings.config" />

However, one realizes that the config source must be in a subfolder of where the the machine.config file is located. So how do you have one, machine wide, location to store all your connection strings?

dko
  • 698
  • 1
  • 6
  • 18
  • Lets say, I have 5 applications. I create 5 installations. Why would I need to deal with a common conn string location if I just can have everything in one folder? And then, when I uninstall, I uninstall one folder - one app, one conn string. No need to worry that I delete a string that also serves other 4 applications. – T.S. Sep 04 '15 at 15:35
  • Wouldn't you have that connection string in each of the 5 app.config's then. We have 30 web applications, each in their own application pool. We want them all connecting to the same database, and depending on the machine it's on, maybe a different database. So we'd have to keep different versions of each of the 30 different web.config's. – dko Sep 04 '15 at 20:54
  • 1
    May be you're too young to remember thing called "DLL-HELL". Long time ago, there was an idea that having shared components was a good thing. Then, developers realized that it wasn't. Hence, each application has its own config, its own set of DLLs (most of the time). So you have 30 applications that use same conn string - this is job of packaging software to supply each of them with appropriate web config or whatever. – T.S. Sep 04 '15 at 21:42
  • 2
    I don't know what you're problem is. I'm not recommending this solution to everyone. For our case it's the best thing that works. We have developers that we don't want to know the connection string on our production boxes. Yes I know dll hell, I experience it frequently. All I'm doing is giving a design option. Normally I do keep connection strings in the individual app.config. In this one specific set of requirements we have.. it doesn't work. If you don't want to use this, then don't. My team was using this before I even started with the company. I'm just trying to share what I've learned. – dko Sep 05 '15 at 21:58
  • Also the app/web.config overrides the machine.config if they happen to have the same connection string name. – dko Sep 05 '15 at 21:58

1 Answers1

2

I couldn't find anywhere on the internet that had this answer. So I am going to answer this myself after some experimentation.

  1. Create a location and place your connectionstrings.config file in there. Ex. C:\Test\Connectionstrings.config
    1. In each of the machine.config locations. For example C:\Windows\Microsoft.net\Framework64\v4.*\Config. Do steps 3 and 4
    2. Open up command prompt as administrator to the the location and run the command:C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config>mklink /D Config C:\Test
    3. Edit the machine.config to be <connectionStrings configSource="Config\connectionStrings.config" />

Now you have one location for all your connection strings.

dko
  • 698
  • 1
  • 6
  • 18
  • Thanks for sharing your solution. I totally disagree with the comments on the original question. We have machines with 100+ applications installed, each with its own set of connection strings for each application. Now we face a database migration. We have no plans on updating 100+ applications as its way too error prone. Centralization is an important option. – webbexpert Oct 18 '18 at 20:49