Как вы используете Machine.config, или вы?

Question

Для развертывания приложений ASP.Net какой тип информации (если есть) вы храните в файле machine.config?

Если вы не используете его, как вы управляете настройками конфигурации среды, которые могут изменяться для каждой среды?

Я ищу некоторые "лучшие практики" и преимущества / ловушки каждого из них. Мы собираемся развернуть новое приложение в производство через два месяца, и у меня есть некоторая свобода в этих типах решений. Я хочу быть уверенным в том, что подхожу к вещам наилучшим образом и стараюсь не выстрелить себе в ногу на более позднем этапе.

FYI В настоящее время мы используем его (machine.config) только для информации о соединении с БД и храним все остальные переменные, которые могут измениться в таблице конфигурации в базе данных.

Answer 1

Если вы распределяете нагрузку на свои серверы, вы ОБЯЗАТЕЛЬНО должны убедиться, что ключ компьютера одинаков на всех серверах. Предполагается, что Viewstate не зависит от сервера, но это не так, поэтому вы получите ошибки, связанные с повреждением ViewState, если ключ компьютера не одинаков на всех серверах.

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

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

PS уверен, что вы можете включить ViewStateMAC = "false", но не включайте.

Answer 2

Мы рассматриваем использование machine.config, чтобы добавить один ключ для среды, а затем иметь один раздел в web.config, который в точности одинаков для всех сред. Таким образом, мы можем сделать «настоящее» развертывание XCopy.

например. в machine.config для каждого компьютера (локальные рабочие станции разработчика, серверы этапов, серверы сборки, производственные серверы) мы добавим следующее:

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

Затем к любому элементу конфигурации, зависящему от среды, добавляется среда, например:

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

Одна проблема, для которой у нас нет решения, это как включить трассировку, скажем, в web.config для среды отладки, а не для реальной среды.

Другая проблема заключается в том, что активная строка подключения вкл. имя пользователя и пароль теперь в вашей системе контроля версий. Однако это не проблема для нас.

Answer 3

Мы используем machine.config на нашем производственном сервере, чтобы установить / удалить определенные конфигурации, которые важны для работы, и мы никогда не забудем их установить.

Это 2 самых важных:

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

Answer 4

Я использую machine.config не только для ASP.NET, но и для общего конфигурирования. Я реализовал алгоритм хэширования (Tiger) в C # и хотел, чтобы он был доступен через машинный запрос. Итак, зарегистрировал мою сборку в GAC и добавил в 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>

Это позволяет моему коду выглядеть так:

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

и в моем коде нет никакой зависимости от сборки Jcs.Tiger.dll, твердой или мягкой.