ASP.NET веб-развертывание с помощью Visual Studio: преобразование файлов Web.config

Том Дайкстра (Tom Dykstra)

Скачать начальный проект

В этой серии руководств показано, как развернуть (опубликовать) веб-приложение ASP.NET для Служба приложений Azure веб-приложения или стороннего поставщика услуг размещения с помощью Visual Studio 2012 или Visual Studio 2010. Сведения о серии см. в первом руководстве этой серии.

Общие сведения

В этом руководстве показано, как автоматизировать процесс изменения файлаWeb.config при его развертывании в разных целевых средах. Большинство приложений имеют параметры в файлеWeb.config , которые должны отличаться при развертывании приложения. Автоматизация процесса внесения этих изменений позволяет вам не выполнять их вручную при каждом развертывании, что может быть мучено и подвержено ошибкам.

Напоминание. Если при работе с руководством появляется сообщение об ошибке или что-то не работает, обязательно проверка страницу устранения неполадок.

Web.config преобразования и параметры веб-развертывания

Существует два способа автоматизировать процесс изменения Web.config параметров файла: Web.config преобразования и параметры веб-развертывания. Файл преобразования Web.config содержит разметку XML, которая указывает, как изменить файлWeb.config при его развертывании. Можно указать различные изменения для конкретных конфигураций сборки и для определенных профилей публикации. Конфигурации сборки по умолчанию — Отладка и Выпуск, и вы можете создавать пользовательские конфигурации сборки. Профиль публикации обычно соответствует целевой среде. (Дополнительные сведения о профилях публикации см. в руководстве Развертывание в IIS в качестве тестовой среды .)

Параметры веб-развертывания можно использовать для указания различных типов параметров, которые необходимо настроить во время развертывания, включая параметры, которые находятся в Web.config файлах. При использовании для указания измененийWeb.config файла параметры веб-развертывания сложнее настроить, но они полезны, если вы не знаете значение, которое необходимо задать до развертывания. Например, в корпоративной среде можно создать пакет развертывания и передать его сотруднику ИТ-отдела для установки в рабочей среде, и этот пользователь должен иметь возможность вводить строки подключения или пароли, которые вам не известны.

Для сценария, описанного в этой серии руководств, вы заранее знаете все, что необходимо сделать с файломWeb.config , поэтому вам не нужно использовать параметры веб-развертывания. Вы настроите некоторые преобразования, которые отличаются в зависимости от используемой конфигурации сборки, а некоторые — в зависимости от используемого профиля публикации.

Указание параметров Web.config в Azure

Если параметры файлаWeb.config, которые вы хотите изменить, находятся в <connectionStrings> элементе или <appSettings> , а развертывание выполняется в веб-приложения в Служба приложений Azure, вы можете автоматизировать изменения во время развертывания. Вы можете ввести параметры, которые вы хотите вступить в силу в Azure, на вкладке Настройка страницы портала управления для веб-приложения (прокрутите вниз до разделов параметры приложения и строки подключения ). При развертывании проекта Azure автоматически применяет изменения. Дополнительные сведения см. в статье Веб-сайты Windows Azure: принципы работы строк приложений и строк подключения.

Файлы преобразования по умолчанию

В Обозреватель решений разверните Web.config, чтобы просмотреть файлы преобразованияWeb.Debug.config и Web.Release.config, созданные по умолчанию для двух конфигураций сборки по умолчанию.

Вы можете создать файлы преобразования для пользовательских конфигураций сборки, щелкнув правой кнопкой мыши файл Web.config и выбрав в контекстном меню пункт Добавить преобразования конфигурации . В этом руководстве вам не нужно это делать, а параметр меню отключен, так как вы еще не создали пользовательские конфигурации сборки.

Позже вы создадите еще три файла преобразования, по одному для тестового, промежуточного и рабочего профилей публикации. Типичным примером параметра, который будет обрабатываться в файле преобразования профиля публикации, так как он зависит от среды назначения, является конечная точка WCF, которая отличается для тестовой и рабочей среды. Вы создадите файлы преобразования профиля публикации в последующих руководствах после создания профилей публикации, с которыми они идут.

Отключение режима отладки

Примером параметра, который зависит от конфигурации сборки, а не целевой debug среды, является атрибут . Для сборки выпуска отладка обычно требуется отключить независимо от среды, в которой выполняется развертывание. Поэтому по умолчанию шаблоны проектов Visual Studio создают Web.Release.config преобразования файлов с помощью кода, который удаляет debug атрибут из compilation элемента . Ниже приведенаWeb.Release.configпо умолчанию: в дополнение к примеру кода преобразования, который закомментирован, он включает код в compilation элементе , который удаляет debug атрибут :

<?xml version="1.0" encoding="utf-8"?>

<!-- For more information on using web.config transformation visit https://go.microsoft.com/fwlink/?LinkId=125889 -->

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!--
    In the example below, the "SetAttributes" transform will change the value of 
    "connectionString" to use "ReleaseSQLServer" only when the "Match" locator 
    finds an attribute "name" that has a value of "MyDB".
    
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>
  -->
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <!--
      In the example below, the "Replace" transform will replace the entire 
      <customErrors> section of your web.config file.
      Note that because there is only one customErrors section under the 
      <system.web> node, there is no need to use the "xdt:Locator" attribute.
      
      <customErrors defaultRedirect="GenericError.htm"
        mode="RemoteOnly" xdt:Transform="Replace">
        <error statusCode="500" redirect="InternalError.htm"/>
      </customErrors>
    -->
  </system.web>
</configuration>

Атрибут xdt:Transform="RemoveAttributes(debug)" указывает, что атрибут debug должен быть удален из system.web/compilation элемента в развернутом Web.config файле. Это будет выполняться при каждом развертывании сборки выпуска.

Ограничение доступа к журналам ошибок для администраторов

Если во время выполнения приложения возникает ошибка, приложение отображает общую страницу ошибок вместо страницы ошибок, созданной системой, и использует пакет NuGet Elmah для ведения журнала ошибок и создания отчетов. Элемент customErrors в файле Web.config приложения указывает страницу ошибки:

<customErrors mode="RemoteOnly" defaultRedirect="~/GenericErrorPage.aspx">
  <error statusCode="404" redirect="~/GenericErrorPage.aspx" />
</customErrors>

Чтобы просмотреть страницу ошибки, временно измените mode атрибут customErrors элемента с RemoteOnly на "Включено" и запустите приложение из Visual Studio. Вызовите ошибку, запросив недопустимый URL-адрес, например Studentsxxx.aspx. Вместо созданной службой IIS страницы ошибки "Ресурс не удается найти", вы увидите страницу GenericErrorPage.aspx .

Чтобы просмотреть журнал ошибок, замените все данные в URL-адресе после номера порта на elmah.axd (например, http://localhost:51130/elmah.axd) и нажмите клавишу ВВОД:

Не забудьте вернуть элемент в customErrors режим RemoteOnly, когда все будет готово.

На компьютере разработки удобно разрешить бесплатный доступ к странице журнала ошибок, но в рабочей среде это может быть угрозой безопасности. Для рабочего сайта необходимо добавить правило авторизации, которое ограничивает доступ к журналам ошибок для администраторов, а также убедиться, что ограничение работает в тестовой и промежуточной среде. Таким образом, это еще одно изменение, которое необходимо реализовать при каждом развертывании сборки выпуска, и поэтому оно принадлежит к файлуWeb.Release.config .

Откройте Web.Release.config и добавьте новый location элемент непосредственно перед закрывающим configuration тегом, как показано здесь.

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!--
    In the example below, the "SetAttributes" transform will change the value of 
    "connectionString" to use "ReleaseSQLServer" only when the "Match" locator 
    finds an attribute "name" that has a value of "MyDB".
    
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>
  -->
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <!--
      In the example below, the "Replace" transform will replace the entire 
      <customErrors> section of your web.config file.
      Note that because there is only one customErrors section under the 
      <system.web> node, there is no need to use the "xdt:Locator" attribute.
      
      <customErrors defaultRedirect="GenericError.htm"
        mode="RemoteOnly" xdt:Transform="Replace">
        <error statusCode="500" redirect="InternalError.htm"/>
      </customErrors>
    -->
  </system.web>
  <location path="elmah.axd" xdt:Transform="Insert">
    <system.web>
      <authorization>
        <allow roles="Administrator" />
        <deny users="*" />
      </authorization>
    </system.web>
  </location>
</configuration>

Значение Transform атрибута Insert приводит к добавлению этого location элемента как одноуровневого элемента во все существующие location элементы в файлеWeb.config . (Уже существует один location элемент, определяющий правила авторизации для страницы "Обновить кредиты ".)

Теперь можно просмотреть преобразование, чтобы убедиться, что оно закодировано правильно.

В Обозреватель решений щелкните правой кнопкой мыши Web.Release.config и выберите пункт Просмотр преобразования.

Откроется страница с файлом Web.config разработки слева и как будет выглядеть развернутый файлWeb.config справа с выделенными изменениями.

( В предварительной версии вы можете заметить некоторые дополнительные изменения, для которых не писали преобразования: обычно они включают удаление пробелов, которые не влияют на функциональность.)

При тестировании сайта после развертывания вы также протестируете, чтобы убедиться, что правило авторизации действует.

Примечание

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

Параметр, который будет обрабатываться в файлах преобразования профиля публикации

Распространенным сценарием является Web.config параметров файла, которые должны отличаться в каждой среде, в которой выполняется развертывание. Например, приложению, которое вызывает службу WCF, может потребоваться другая конечная точка в тестовой и рабочей средах. Приложение Университета Contoso также включает параметр такого рода. Этот параметр управляет видимым индикатором на страницах сайта, который сообщает, в какой среде вы находитесь, например в среде разработки, тестирования или рабочей среды. Значение параметра определяет, будет ли приложение добавлять "(Dev)" или "(Test)" к заголовку main на странице master Site.Master:

Индикатор среды опущен, когда приложение выполняется в промежуточной или рабочей среде.

Веб-страницы Университета Contoso считывают значение, заданное в appSettings файле Web.config , чтобы определить, в какой среде выполняется приложение:

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

Значение должно быть "Test" в тестовой среде и "Prod" для промежуточной и рабочей среды.

Следующий код в файле преобразования реализует это преобразование:

<appSettings>
    <add key="Environment" value="Test" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>

Значение xdt:Transform атрибута SetAttributes указывает, что цель этого преобразования заключается в изменении значений атрибутов существующего элемента в файлеWeb.config . Значение xdt:Locator атрибута Match(key)" указывает, что изменяемый элемент является элементом, атрибут которого key соответствует атрибуту, указанному key здесь. Единственным другим атрибутом add элемента является value, который будет изменен в развернутом Web.config файле. Приведенный здесь код задает value для атрибута EnvironmentappSettings элемента значение Test в развернутом файлеWeb.config .

Это преобразование относится к файлам преобразования профиля публикации, которые вы еще не создали. Вы создадите и обновите файлы преобразования, реализующие это изменение, при создании профилей публикации для тестовой, промежуточной и рабочей сред. Это можно сделать в руководствах по развертыванию в IIS и развертыванию в рабочей среде .

Примечание

Так как этот параметр находится в элементе <appSettings> , при развертывании в веб-приложения в Служба приложений Azure см. раздел Указание параметров Web.config в Azure ранее в этом разделе.

Настройка строк подключения

Хотя файл преобразования по умолчанию содержит пример, в котором показано, как обновить строку подключения, в большинстве случаев не требуется настраивать преобразования строки подключения, так как строки подключения можно указать в профиле публикации. Это можно сделать в руководствах по развертыванию в IIS и развертыванию в рабочей среде .

Итоги

Теперь вы сделали все возможное с помощьюWeb.config преобразований, прежде чем создавать профили публикации, и вы видели предварительный просмотр того, что будет в развернутом файле Web.config.

В следующем руководстве вы позаботитесь о задачах настройки развертывания, требующих установки свойств проекта.

Дополнительные сведения

Дополнительные сведения о темах, рассматриваемых в этом руководстве, см. в статье Использование преобразований Web.config для изменения параметров в целевом файле Web.config или app.config файле во время развертывания в схеме содержимого веб-развертывания для Visual Studio и ASP.NET.

НазадВперед