Reputation: 2852
Let's say there is a .Net solution with 2 Class Library projects: one is Data Access layer and the other is Business Logic layer. These projects have a app.config
file. There's also one Web project and one Windows Forms project and each have their own config file as well i.e app.config
and web.config
respectively.
Now, if I set the Windows Forms project be the startup project, run it and inspect the settings via ConfigurationSettings.AppSettings.Get("Some-key")
, it turns out that I have access only to the Windows Forms settings which implies I have to put all of the application settings in this file. Also, I need to duplicate the setting in the web.config
(I'm still not sure this is the expected behaviour or I had to do things differently. Can somebody shed any light here?)
My questions is: does it make any sense to distribute the application configurations in related projects (for example keeping database connection string in Data Access project config file)?
If yes, how do we access the settings of one assembly from another one then?
If no, why does .Net create config file for non-executable projects at all?
Third question: is there a neat and easy way to consolidate config files?
Upvotes: 0
Views: 72
Reputation: 152596
does it make any sense to distribute the application configurations in related projects (for example keeping database connection string in Data Access project config file)?
No - they will be ignored. Only the config file for the executing assembly will be used (barring any special settings to import other configs, etc.)
how do we access the settings of one assembly from another one then?
Assemblies aren't configured; Applications are. That is why app.config
should contain ALL of the information necessary to configure not just the executable, but all dependent assemblies as well.
why does .Net create config file for non-executable projects at all?
So you have an example to know what settings the assembly uses.
is there a neat and easy way to consolidate config files?
There are tools and hacks out there to make it a bit easier (feel free to search around), but in my experience it's not too burdensome to just copy/paste the settings from the generated assembly into the executable project config. Plus, I often have multiple configs per project (for dev/test/prod environments) that are configured differently, so auto-genning the main project config can get complicated in those types of scenarios.
Upvotes: 2
Reputation: 210
If you want to have a common config file for multiple projects, create a class library project with a config file, and create public properties for your app settings as public properties available for other projects.
Upvotes: 0