Развертывание веб-приложения ASP.NET с помощью SQL Server Compact с помощью Visual Studio или Visual Web Developer: преобразования файлов Web.Config — 3 из 12
В этой серии руководств показано, как развернуть (опубликовать) проект веб-приложения ASP.NET, включающий базу данных SQL Server Compact с помощью RC-кандидата Visual Studio 2012 или RC-кандидата Visual Studio Express 2012 для Интернета. Вы также можете использовать Visual Studio 2010, если установить обновление веб-публикации. Общие сведения о серии см . в первом руководстве серии.
В руководстве по использованию функций развертывания, представленных после выпуска RC Visual Studio 2012, показано, как развертывать выпуски SQL Server, отличные от SQL Server Compact, и показано, как развернуть в приложение Azure service веб-приложения, см. 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 .
Ограничение доступа к журналам ошибок администраторам
Если во время выполнения приложения возникает ошибка, приложение отображает универсальную страницу ошибок вместо страницы ошибки, созданной системой, и он использует пакет Elmah NuGet для ведения журнала ошибок и создания отчетов. Элемент 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 элемент, указывающий правила авторизации для страницы Update Credits .) При тестировании рабочего сайта после развертывания необходимо проверить, является ли это правило авторизации эффективным.
Вам не нужно ограничивать доступ к журналам ошибок в тестовой среде, поэтому вам не нужно добавлять этот код в файл конфигурации Web.Test.config .
Примечание.
Примечание по безопасности никогда не отображает сведения об ошибке для общественности в рабочем приложении или храните эти сведения в общедоступном расположении. Злоумышленники могут использовать сведения об ошибках для обнаружения уязвимостей на сайте. Если вы используете ELMAH в собственном приложении, обязательно изучите способы настройки ELMAH для минимизации рисков безопасности. Пример ELMAH в этом руководстве не должен считаться рекомендуемой конфигурацией. Это пример, выбранный для иллюстрации того, как обрабатывать папку, в которую приложение должно иметь возможность создавать файлы.
Настройка индикатора среды
Распространенный сценарий — иметь параметры файла web.config , которые должны отличаться в каждой среде, в которой выполняется развертывание. Например, приложению, вызывающей службу WCF, может потребоваться другая конечная точка в тестовой и рабочей средах. Приложение Contoso University также включает в себя параметр такого рода. Этот параметр управляет видимым индикатором на страницах сайта, указывающих, в какой среде вы находитесь, например разработка, тестирование или рабочая среда. Значение параметра определяет, будет ли приложение добавлять "(Dev)" или "(Test)" в основной заголовок на главной странице Сайта.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 к тому, что атрибут Environment appSettings элемента должен иметь значение "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.