Answered by:
Web.config and setting files - Changing default location for Web.config file

Question
-
Hi everyone
I've got a tricky questions (maybe not but for me) my initial situations is as follows:
My Web.config file and the corresponding transform files are located in a different folder [project root]\config\deployment and will be copied and transformed everytime I build my solution to [project root]\Web.config . That's because every developer can use there own transform files for local debugging and developing.
Unfortunately this setup has a major drawback as we use several setting files which tries to keep in sync with that dynamiclly created Web.config file.
So my questions is, is it possible to tell VS2010 to sync those setting files with a web.config file in a different location as the default one?
Every answer is greatly appreciated
greeetz Confederatio
Friday, December 7, 2012 7:08 AM
Answers
-
The Settings file is going to update the project's config file. You cannot change that functionality. You're also going to introduce issues with other things like adding connection strings, using EF, just about any NuGet package that wants to update config entries, etc. I recommend that you do not modify how the config system works. Your web.config should reside in the root of the app as is expected. Then everything works.
I'm not sure why each of your devs would need their own config files. In general you would want all settings to be environment agnostic except where absolutely necessary, that's were the transforms come in. Ideally there should be no (or very little) per-user settings. For those you have a couple of options. The simplest option is to add a setting that is per-user. The default value goes in the web.config and the per-dev setting goes in the user's config file. Devs can manually change the file as needed. This is sort of counter-intuitive given that it is a web app but for the specific case of only needing per-dev settings then it actually works really well.
Another option that is a little more advanced (but more powerful) is to use a separate config file altogether for things that have to be per-dev. This is a common approach used by third-party components like loggers and IoC containers. The downside is that you'll be using a different API to get access to the data than the normal Configuration subsystem but if you're isolating this into a configuration type then it doesn't really matter.
Yet another option is to support an optional config file (mysettings.config or something) that is read in, if available, at startup. The config file can override the settings in the web.config. This would require more work but would allow you to continue using the Configuration subsystem. Outside the dev environment there would be no custom config so the app would behave normally.
Michael Taylor - 12/7/2012
http://msmvps.com/blogs/p3net
- Marked as answer by Confederatio Helvetica Friday, December 7, 2012 8:55 PM
Friday, December 7, 2012 3:45 PMModerator
All replies
-
The Settings file is going to update the project's config file. You cannot change that functionality. You're also going to introduce issues with other things like adding connection strings, using EF, just about any NuGet package that wants to update config entries, etc. I recommend that you do not modify how the config system works. Your web.config should reside in the root of the app as is expected. Then everything works.
I'm not sure why each of your devs would need their own config files. In general you would want all settings to be environment agnostic except where absolutely necessary, that's were the transforms come in. Ideally there should be no (or very little) per-user settings. For those you have a couple of options. The simplest option is to add a setting that is per-user. The default value goes in the web.config and the per-dev setting goes in the user's config file. Devs can manually change the file as needed. This is sort of counter-intuitive given that it is a web app but for the specific case of only needing per-dev settings then it actually works really well.
Another option that is a little more advanced (but more powerful) is to use a separate config file altogether for things that have to be per-dev. This is a common approach used by third-party components like loggers and IoC containers. The downside is that you'll be using a different API to get access to the data than the normal Configuration subsystem but if you're isolating this into a configuration type then it doesn't really matter.
Yet another option is to support an optional config file (mysettings.config or something) that is read in, if available, at startup. The config file can override the settings in the web.config. This would require more work but would allow you to continue using the Configuration subsystem. Outside the dev environment there would be no custom config so the app would behave normally.
Michael Taylor - 12/7/2012
http://msmvps.com/blogs/p3net
- Marked as answer by Confederatio Helvetica Friday, December 7, 2012 8:55 PM
Friday, December 7, 2012 3:45 PMModerator -
Hi CoolDadTx
Thank you a lot for your detailed answer. I haven't thought so far that other designer tools will also write into the web.config file. I will consider your recommendations, but probably i give a try your third proposal.
Again thanks a lot for your explanations.
Greeetz
ConfederatioFriday, December 7, 2012 9:07 PM