How are you using the Machine.config, or are you?

Question

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.

Answer 1

I use machine.config for not just ASP.NET, but for overall config as well. I implemented a hash algorithm (Tiger) in C# and wanted it to be available via machine request. So, registered my assembly in the GAC and added the following to machine.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <mscorlib>
        <cryptographySettings>
            <cryptoNameMapping>
                <cryptoClasses>
                    <cryptoClass Tiger192="Jcs.Tiger.Tiger192, Jcs.Tiger, Culture=neutral, PublicKeyToken=66c61a8173417e64, Version=1.0.0.4"/>
                    <cryptoClass Tiger160="Jcs.Tiger.Tiger160, Jcs.Tiger, Culture=neutral, PublicKeyToken=66c61a8173417e64, Version=1.0.0.4"/>
                    <cryptoClass Tiger128="Jcs.Tiger.Tiger128, Jcs.Tiger, Culture=neutral, PublicKeyToken=66c61a8173417e64, Version=1.0.0.4"/>
                </cryptoClasses>
                <nameEntry name="Tiger" class="Tiger192"/>
                <nameEntry name="TigerFull" class="Tiger192"/>
                <nameEntry name="Tiger192" class="Tiger192"/>
                <nameEntry name="Tiger160" class="Tiger160"/>
                <nameEntry name="Tiger128" class="Tiger128"/>
                <nameEntry name="System.Security.Cryptography.HashAlgorithm" class="Tiger192"/>
            </cryptoNameMapping>
            <oidMap>
                <oidEntry OID="1.3.6.1.4.1.11591.12.2" name="Jcs.Tiger.Tiger192"/>
            </oidMap>
        </cryptographySettings>
    </mscorlib>
</configuration>

This allows my code to look like so:

using (var h1 = HashAlgorithm.Create("Tiger192"))
{
   ...
}

and there's no dependency on the Jcs.Tiger.dll assembly in my code at all, hard or soft.

Answer 2

If you load balance your servers, you ABSOLUTELY have to make sure the machine key is the same on all the servers. Viewstate is supposed to be server agnostic, but it is not, so you'll get viewstate corruption errors if the machine key is not the same across servers.

<machineKey validationKey='A130E240DF1C49E2764EF8A86CEDCBB11274E5298A130CA08B90EED016C0
14CEAE1D86344C29E67E99DF83347E43820050A2B9C9FC89E0574BF3394B6D0401A9'
decryptionKey='2CC37FFA8D14925B9CBCC0E3B1506F35066FEF33FEB4ADC8' validation='SHA1'/>

From: http://www.c-sharpcorner.com/UploadFile/gopenath/Page107182007032219AM/Page1.aspx

PS sure you can enableViewStateMAC="false", but don't.

Answer 3

We use machine.config on our production server to set/remove specific configuration that are important for production and we never want to forget to set them.

These are the 2 most important:

<system.web>
    <deployment retail="true" />
    <healthMonitoring enabled="true" />
</system.web> 

Answer 4

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.