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

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

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

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

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

Ответ 1

Мы рассматриваем использование 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 для среды отладки, а не для живой среды.

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

Ответ 2

Если вы загружаете баланс на свои серверы, вы должны убедиться, что машинный ключ на всех серверах одинаковый. Предполагается, что Viewstate является агностиком сервера, но это не так, поэтому вы получите ошибки коррупции в представлении, если машинный ключ не совпадает с сервером.

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

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

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

Ответ 3

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

Это два наиболее важных:

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

Ответ 4

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