Single config file for solution

Question

Now I have seen this question before on SO in a variant ways, but surprisingly not in this form:

I have a solution with multiple web services (projects) that need to talk to each other. After publishing each of these web services might end up on a different machine with a different database. To tell each web service where all other web services are, I want to maintain a single config file during development.

I would like to expect that after publishing the config to be present in each published project. And I would like to expect the config file to be editable after publishing, so I can swiftly migrate a certain web service and then just edit all config files of the other web services.

I don't want to do this in the database, for the config file its self should also hold connection settings to the database(s).

I came across the following ideas/thoughts/questions:

• I have a dll project called 'common' that is referenced by other projects. Let's give that one a shared.config and build a class in that project that can be used to read out the shared.config by doing System.Configuration.ConfigurationManager.OpenExeConfiguration("shared.config"). Just need to make sure the shared.config will be published along with the DLL.

I would favor this solution, as it would also let me keep a web.config inside each project having just the project specific settings. And have the shared.config having the shared settings. But I read on SO that this should not be considered lightly and could have some unwanted side-effects, like file-access-issues; though I wonder if this would apply to my case. Also I would like to ask your help here on how to actually realize this as I don't think Visual Studio supports app.config for DLL projects out of the box.

• I also thought about creating a shared.config file in the Solution Items. Then linking that file inside each project. And in the Web.config of each projects, add: <appSettings configSource="shared.config" /> pointing to the linked file in that project.

Though I cannot find any reason why not to do this, first implementation failed. It seems (at least during development), c# cannot find the linked shared.config file. I'm guessing linking files is not done instantly nor maintained after creating the linked file, but the file is only copied to the projects WHEN I do a publish. Thus leaving the file missing during development. Is this correct?

Answer 1

The config files are app specific. This mean that you can add a config file to a class library but the file will then by used by the app (windows service, webservice and so on) referencing the library.

Same thing for external configSource, this are app specific as well and need to be included withing the project using it. So if your solution is composed by 2 projects you then need 2 config files. One for each project.

While for a windows based application(services, winforms) the expected folder for config files is the bin directory, for web based projects this will be the directory is the root folder of the virtual directory.

This said, using a shared config file looks the easier solution (and you don't have to copy the app.config from the class library for each project). Here are the steps :

• Create a solution folder.
• Add the config file to it.
• Add the file as a reference for each project needing it. Right click the project and Add existing item - > Choose the file and Add as link
• Ensure the file is always copied by setting the copy option (properties of the file) with Copy Always.

At this point you should have the config file deployed into your project directory everytime you compile the solution.

EDIT:

• I'd avoid looking into the bin for config files within a web app, the convention is that file should be in the root, so I would avoid the first option.
• Linked files end up in the bin after building the project. Try the same steps for importing the file but this time simply add it (not as link) and it will be deployed as content in the root of your site, so it can be always available.