0

There are 4 of us working on a solution right now. The solution consists of a central executable project (a Windows service) and a number of Class Library solutions. The Windows service has an app.config file, but the Copy to Output Directory setting for it is set to "Do not copy" for some reason, so we can ignore it for this discussion.

There are two different Class Library projects that have app.config files. In one of the projects, this gets copied into the bin\Debug folder as MyClassLibrary.dll.config, while the other DLL's bin\Debug folder has both a MyOtherClassLibrary.dll.config AND app.config in it. I'm not sure how that happened.

These are all of the app.config files in the solution.

There is an MSTest project in the solution. It has several classes with the [TestClass] attributes on them, each in their own .cs file. When I look at this project's bin\Debug folder, I find the MyClassLibrary.dll and App.config in it, but no MyOtherClassLibrary.dll. This is odd, but that's what I see.

When I go to run one of these tests, as you know, files get copied into a special test folder in the solution's TestResults folder. When I look in that folder, I find only a MyTestProject.dll.config file. And when I open this, its contents are those of the app.config file.

What's going on here? I thought Visual Studio merged all of the config files together? The lack of the settings from the MyClassLibrary.dll.config file (obviously) breaks the code that relies on it.

How do we fix this?

Tony

EDIT:

I just double checked the MyClassLibrary bin\Debug folder & that has both app.config & MyClassLibrary.dll.config, so I guess what I was seeing in MyOtherClassLibrary is normal. We just need a way to manage all of these settings.

Tony Vitabile
  • 8,298
  • 15
  • 67
  • 123

4 Answers4

1

No, VS does NOT merge config files together. It does not do this because it is possible to have a solution that generates two or more executables as projects. Even for projects that always end up as class libraries and there's only ever one executable, it's not a good idea to merge app.configs because of separation of concerns; the project library should be a "black box" that referencing code only needs an external interface to via instantiating methods and calling methods. An app.config and its information is by definition an implementation detail, which only the project that needs it should know, and NOT the projects that reference it. Besides, if you recompiled the project library independently from another executable and just pushed out the new DLL, how would the config files be merged then?

If a project has an app.config, a config will be created for that project specifically, distinct and separate from all others.

If your configs have common data in common sections, you can minimize the amount of redundant data by specifying an external config file for those sections and referencing it from each project's "main" config file using "configSource" attributes.

KeithS
  • 70,210
  • 21
  • 112
  • 164
  • We guessed that these "configSource" attributes you speak of would go into Assembly.info, but we can't seem to find any "configSource" attributes. Can you elaborate on where these go and what exactly they're called? – Tony Vitabile Oct 21 '11 at 19:04
  • The configSource attributes go in the app.config, and are used to "link" one config file to another. You can thus use the same configSource in both of your projects' config files and have the same data without duplication. – KeithS Oct 21 '11 at 23:51
0

Just remember that there is two things that happen with a config file like this (including web.config and app.config files):

  1. You deploy the file as is. It may be subject to transforms but the file is deployed with the name as it is.

  2. It gets compiled as belonging to the assembly. So my project named ProjectOne will have it's App.Config file compiled and renamed as ProjectOne.dll.config (assuming my assembly for ProjectOne is "ProjectOne")

This is important because its all about scope. This renaming is by design as it still allows a project assembly to access its own config file first. These will take priority over those of the actual app.config from scenario 1.

You can prevent scenario 2 from occurring by changing the properties of the file so that MSBuild does not touch the file. Then it may attempt to deploy it as is. In this situation it will overwrite any previously deployed ones based on build order.

csharpforevermore
  • 1,472
  • 15
  • 27
0

You should only need one config file and it can be part of the executing project (i.e. console project, web application project, etc). If your class from one of the class libraries is referencing a config value, it should have access/scope to it from the executing project. I have never seen any automatic merging.

Justin Helgerson
  • 24,900
  • 17
  • 97
  • 124
  • Not sure where I got the idea that multiple configuration files would be merged. In any case, that's clearly wrong as everyone who has answered has told me. So, essentially, if there's an app.config in a TEST project, that one trumps all the others that might come in with other DLLs when TST copies the bin folder to the TESTRESULTS folder. Is this right? – Tony Vitabile Oct 21 '11 at 19:02
0

You pull your settings into your main config or implement something that merges some on build, I touch upon this in a somewhat related way here: Visual studio 2010 - Per Developer/machine/environment Web.Config settings

You will not get anything automatically copied by default outside of your main config, it doesn't work that way.

Community
  • 1
  • 1
Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71