Развертывание веб-приложения ASP.NET с помощью SQL Server Compact с помощью Visual Studio или Visual Web Developer: преобразование файлов Web.Config — 3 из 12

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

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

В этой серии руководств показано, как развернуть (опубликовать) проект веб-приложения ASP.NET, включающий базу данных SQL Server Compact, с помощью версии-кандидата Visual Studio 2012 или Visual Studio Express 2012 RC for Web. Вы также можете использовать Visual Studio 2010 при установке обновления веб-публикации. Общие сведения о серии см. в первом руководстве этой серии.

Руководство по функциям развертывания, появившиеся после выпуска версии-кандидата Visual Studio 2012, развертывание SQL Server выпусков, отличных от SQL Server Compact, а также развертывание в Служба приложений Azure веб-приложения, см. в статье ASP.NET веб-развертывание с помощью Visual Studio.

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

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

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

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

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

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

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

Создание файлов преобразования для профилей публикации

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

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

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

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

В Windows Обозреватель выберите файлWeb.Release.config, скопируйте файл и вставьте две его копии. Переименуйте эти копии Web.Production.config и Web.Test.config, а затем закройте windows Обозреватель.

В Обозреватель решений нажмите кнопку Обновить, чтобы просмотреть новые файлы.

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

Чтобы предотвратить развертывание этих файлов, выберите их в Обозреватель решений, а затем в окне Свойства измените свойство Действие сборки с Content на None. (Файлы преобразования, основанные на конфигурациях сборки, автоматически блокируются при развертывании.)

Теперь все готово для ввода Web.config преобразований в файлы преобразования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.Production.config .

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

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <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.Test.config .

Примечание

Примечание по безопасности Никогда не отображайте сведения об ошибке в общедоступном рабочем приложении и не храните эти сведения в общедоступном расположении. Злоумышленники могут использовать сведения об ошибках для обнаружения уязвимостей на сайте. Если вы используете 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" в рабочей среде.

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

<appSettings>
    <add key="Environment" value="Prod" 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 элемента значение "Prod" в файлеWeb.config , развернутом в рабочей среде.

Затем примените то же изменение к Web.Test.config файлу, за исключением того, что задайте для параметра value значение "Test" вместо "Prod". По завершении appSettings раздел в Web.Test.config будет выглядеть следующим образом:

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

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

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

<system.web>
  <compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>

Атрибут Transform приводит к пропуску атрибута debug из развернутого файлаWeb.config при каждом развертывании сборки выпуска.

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

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

В большинстве случаев не требуется настраивать преобразования строк подключения, так как можно указать строки подключения в профиле публикации. Однако при развертывании базы данных SQL Server Compact и использовании Entity Framework Code First Migrations для обновления базы данных на целевом сервере существует исключение. В этом сценарии необходимо указать дополнительную строку подключения, которая будет использоваться на сервере для обновления схемы базы данных. Чтобы настроить это преобразование, добавьте <элемент connectionStrings> сразу после открывающего <тега конфигурации> в файлы Web.Test.config и Web.Production.config преобразования:

<connectionStrings>
  <add name="SchoolContext_DatabasePublish" connectionString="Data Source=|DataDirectory|School-Prod.sdf" providerName="System.Data.SqlServerCe.4.0" xdt:Transform="Insert"/>
</connectionStrings>

Атрибут Transform указывает, что эта строка подключения будет добавлена в элемент connectionStrings в развернутом файлеWeb.config . (Процесс публикации автоматически создает эту дополнительную строку подключения, если она не существует, но по умолчанию атрибут providerName получает значение System.Data.SqlClient, что не работает для SQL Server Compact. Добавляя строку подключения вручную, вы не позволяете процессу развертывания создать элемент строки подключения с неправильным именем поставщика.)

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

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

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

НазадВперед