For ASP.Net application deployment what type of information (if any) are you storing in the machine.config?
If you're not using it, how are you managing environment specific configuration settings that may change for each environment?
I'm looking for some "best practices" and the benefits/pitfalls of each. We're about to deploy a brand new application to production in two months and I've got some latitude in these types of decisions. I want to make sure that I'm approaching things in the best way possible and attempting to avoid shooting myself in the foot at a later date.
FYI We're using it (machine.config) currently for just the DB connection information and storing all other variables that might change in a config table in the database.
We are considering using machine.config to add one key for the environment, and then have one section in the web.config which is excactly the same for all environments. This way we can do a "real" XCopy deployment.
E.g. in the machine.config for every computer (local dev workstations, stage servers, build servers, production servers), we'll add the following:
<appSettings> <add key="Environment" value="Staging"/> </appSettings>
Then, any configuration element that is environment-specific gets the environment appended, like so:
<connectionStrings> <add name="Customers.Staging" provider="..." connectionString="..."/> </connectionStrings> <appSettings> <add key="NTDomain.Staging" value="test.mydomain.com"/> </appSettings>
One problem that we don't have a solution for is how to enable say tracing in web.config for debugging environment and not for live environment.
Another problem is that the live connectionstring incl. username and password is now in your Source Control system. This is however not a problem for us.