¿Cómo está usando Machine.config, o es usted?

Question

Para la implementación de aplicaciones ASP.Net, ¿qué tipo de información (si existe) está almacenando en machine.config?

Si no lo está utilizando, ¿cómo está administrando las configuraciones de configuración específicas del entorno que pueden cambiar para cada entorno?

Estoy buscando algunas "mejores prácticas" y los beneficios/riesgos de cada uno. Estamos a punto de implementar una nueva aplicación para la producción en dos meses y tengo algo de flexibilidad en este tipo de decisiones. Quiero asegurarme de que estoy abordando las cosas de la mejor manera posible y tratando de evitar dispararme en el pie en una fecha posterior.

FYI Lo estamos usando (machine.config) actualmente solo para la información de conexión DB y almacenando todas las demás variables que pueden cambiar en una tabla de configuración en la base de datos.

Answer 1

Estamos considerando utilizar machine.config para agregar una clave para el entorno, y luego tenemos una sección en el web.config que es exactamente igual para todos los entornos. De esta manera podemos hacer una implementación XCopy "real".

E.g. en el machine.config para cada equipo (estaciones de trabajo, servidores locales dev etapa, construir servidores, servidores de producción), añadiremos lo siguiente:

<appSettings> 
    <add key="Environment" value="Staging"/> 
</appSettings> 

Entonces, cualquier elemento de configuración que es el medio ambiente específico que sufre el medio ambiente anexa, así:

<connectionStrings> 
    <add name="Customers.Staging" provider="..." connectionString="..."/> 
</connectionStrings> 
<appSettings> 
    <add key="NTDomain.Staging" value="test.mydomain.com"/> 
</appSettings> 

un problema que no tenemos una solución para es cómo habilitar el rastreo decir en web.config para depurar el medio ambiente y no para el medio ambiente en vivo.

Otro problema es que la conexión de la línea viva incl. nombre de usuario y contraseña están ahora en su sistema de control de fuente. Sin embargo, esto no es un problema para nosotros.

Answer 2

Uso machine.config no solo para ASP.NET, sino también para la configuración general. Implementé un algoritmo hash (Tiger) en C# y quería que estuviera disponible a través de la solicitud de la máquina. Así, registrado mi ensamblado en la GAC ​​y añade el siguiente texto en 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> 

Esto permite que mi código para que parezca así:

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

y no hay dependencia de la Jcs.Tiger. dll montaje en mi código, duro o blando.

Answer 3

Utilizamos machine.config en nuestro servidor de producción para establecer/eliminar configuraciones específicas que son importantes para la producción y nunca queremos olvidarnos de configurarlas.

Estos son los 2 más importantes:

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

Answer 4

Si carga a equilibrar sus servidores, es absolutamente necesario para asegurarse de que la clave del equipo es el mismo en todos los servidores. Se supone que Viewstate es independiente del servidor, pero no lo es, por lo que obtendrá errores de corrupción de estado de vista si la clave del equipo no es la misma en todos los servidores.

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

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

PS asegurarse de que puede enableViewStateMAC = "false", pero no lo hacen.