Comment utilisez-vous Machine.config, ou êtes-vous?

Question

Pour le déploiement de l'application ASP.Net, quel type d'informations (le cas échéant) stockez-vous dans le fichier machine.config?

Si vous ne l'utilisez pas, comment gérez-vous les paramètres de configuration spécifiques à l'environnement qui peuvent changer pour chaque environnement?

Je suis à la recherche de «bonnes pratiques» et des avantages/pièges de chacune. Nous sommes sur le point de déployer une nouvelle application à la production dans deux mois et j'ai une certaine latitude dans ce genre de décisions. Je veux m'assurer que j'aborde les choses de la meilleure façon possible et que j'essaie d'éviter de me tirer une balle dans le pied à une date ultérieure.

FYI Nous l'utilisons actuellement (machine.config) pour seulement les informations de connexion à la base de données et pour stocker toutes les autres variables qui pourraient changer dans une table de configuration dans la base de données.

Answer 1

Nous envisageons d'utiliser machine.config pour ajouter une clé pour l'environnement, puis une section dans le fichier web.config qui est exactement la même pour tous les environnements. De cette façon, nous pouvons faire un "vrai" déploiement XCopy.

E.g. dans le machine.config pour chaque ordinateur (postes de travail dev locaux, serveurs de scène, construire des serveurs, des serveurs de production), nous allons ajouter ce qui suit:

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

Ensuite, tout élément de configuration de l'environnement spécifique a l'environnement en annexe, comme suit:

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

un problème que nous n'avons pas une solution pour permettre est de savoir comment dire le traçage dans web.config pour l'environnement de débogage et non pour l'environnement en direct.

Un autre problème est que la chaîne de connexion en direct incl. nom d'utilisateur et mot de passe est maintenant dans votre système de contrôle de la source. Ce n'est cependant pas un problème pour nous.

Answer 2

J'utilise machine.config non seulement pour ASP.NET, mais aussi pour la configuration globale. J'ai implémenté un algorithme de hachage (Tiger) en C# et je voulais qu'il soit disponible via une requête machine. Ainsi, enregistré mon assemblage dans le GAC et a ajouté ce qui suit 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> 

Cela permet à mon code pour ressembler à ceci:

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

et il n'y a pas de dépendance à l'égard Jcs.Tiger. dll assemblage dans mon code du tout, dur ou doux.

Answer 3

Nous utilisons machine.config sur notre serveur de production pour définir/supprimer la configuration spécifique qui est importante pour la production et nous ne voulons jamais oublier de les définir.

Ce sont les deux plus importantes:

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

Answer 4

Si vous équilibrer la charge entre vos serveurs, vous devez absolument vous assurer que la clé de la machine est la même sur tous les serveurs. Viewstate est censé être indépendant du serveur, mais ce n'est pas le cas. Vous obtiendrez donc des erreurs de corruption de viewstate si la clé de la machine n'est pas la même sur tous les serveurs.

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

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

PS que vous pouvez enableViewStateMAC = "false", mais ne le font pas.