Использовать преобразование web.config Visual Studio для отладки

Ответ 1

ОК, при том понимании, что web.debug.config и web.release.config предназначены только для пакета/публикации. Я придумал способ, чтобы вы могли делать то, что вы пытаетесь сделать. Я писал об этом в http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx. Вот резюме.

Теперь посмотрим, как мы можем включить то, что хочет задать вопрос.

Чтобы повторить, когда он строит на определенной конфигурации, он хочет, чтобы для web.config применялось определенное преобразование. Поэтому, очевидно, вы не хотите поддерживать файл web.config, потому что он будет перезаписан.

Итак, нам нужно создать новый файл web.template.config, который является просто копией web.config. Затем просто удалите web.config с помощью проводника Windows (не удаляйте с помощью Visual Studio, потому что мы не хотим его удалять из проекта).

Примечание. Если вы используете поставщик управления версиями, который интегрирован в Visual Studio, вы, вероятно, захотите удалить web.config из исходного элемента управления.

Кроме того, мы не хотим использовать web.debug.config или web.release.config, потому что они уже имеют четко определенную роль в веб-публикации, поэтому мы не хотим этого беспокоить. Поэтому вместо этого мы создадим два новых файла в той же папке, что и проект, и web.template.config, web.dev.debug.config и web.dev.release.config.

Идея заключается в том, что это будут преобразования, применяемые при отладке или запуске вашего приложения из Visual Studio. Теперь нам нужно подключиться к процессу сборки/пакета/публикации, чтобы все это подключалось. В проектах веб-приложений (WAP) существует точка расширяемости, в которой вы можете создать файл проекта в той же папке с именем {ProjectName}.wpp.targets, где {ProjectName} - это имя проекта. Если этот файл находится на диске в той же папке, что и WAP, он будет автоматически импортирован в файл проекта. Поэтому я создал этот файл. И я разместил следующий контент:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <!-- Make sure web.config will be there even for package/publish -->
  <Target Name="CopyWebTemplateConfig" BeforeTargets="Build">
    <Copy SourceFiles="web.template.config"
          DestinationFiles="web.config"/>
  </Target>

  <PropertyGroup>
    <PrepareForRunDependsOn>
      $(PrepareForRunDependsOn);
      UpdateWebConfigBeforeRun;
    </PrepareForRunDependsOn>
  </PropertyGroup>

  <!-- This target will run right before you run your app in Visual Studio -->
  <Target Name="UpdateWebConfigBeforeRun">
    <Message Text="Configuration: $(Configuration): web.dev.$(Configuration).config"/>
    <TransformXml Source="web.template.config"
              Transform="web.dev.$(Configuration).config"
              Destination="web.config" />
  </Target>

  <!-- Exclude the config template files from the created package -->
  <Target Name="ExcludeCustomConfigTransformFiles" BeforeTargets="ExcludeFilesFromPackage">
    <ItemGroup>
      <ExcludeFromPackageFiles Include="web.template.config;web.dev.*.config"/>
    </ItemGroup>
    <Message Text="ExcludeFromPackageFiles: @(ExcludeFromPackageFiles)" Importance="high"/>
  </Target>
</Project>

Позвольте мне немного объяснить это. Я создал цель CopyWebTemplateConfig, которая всегда будет копировать web.template.config в web.config при сборке, даже если вы не отлаживаете свое приложение в Visual Studio.

Это необходимо, потому что нам еще нужно поддерживать процесс пакет/публикация Visual Studio. Затем я расширил свойство PrepareForRunDependsOn, включив в него цель UpdateWebConfigBeforeRun. Это свойство используется для определения списка целей, которые должны быть выполнены до запуска любого управляемого проекта из Visual Studio.

В этой цели я использую задачу TransformXml для преобразования web.template.config, используя правильный файл web.dev.***.config. После этого ваше приложение запускается с использованием правильного web.config на основе вашей конфигурации сборки. После этого у меня есть другая цель ExcludeCustomConfigTransformsFiles, которую я вставляю в процесс package/publish через атрибут BeforeTargets="ExcludeFilesFromPackage". Это необходимо, потому что мы не хотим, чтобы эти файлы включались, когда приложение было упаковано или опубликовано. Так что это действительно все.

Объяснить процесс пакета/публикации немного больше для этого сценария. Когда вы упаковываете/публикуете web.debug.config или web.release.config, в зависимости от конфигурации сборки все равно будет использоваться. Но в конечном итоге файл, который он преобразует, web.template.config, поэтому вам, возможно, придется настраивать в зависимости от того, что у вас есть в этом файле. Вопросы/Комментарии?

Ответ 2

Эндрю на правильном пути. Когда вы используете эту функцию, вот как она была разработана для использования.

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

web.debug.config Это преобразование, которое применяется при публикации вашего приложения в среде промежуточной разработки. Это приведет к изменениям в web.config, которые необходимы для целевой среды.

web.release.config Это преобразование, которое применяется при публикации вашего приложения в "производственной" среде. Очевидно, что вам придется быть осторожным с паролями в зависимости от вашего приложения/команды.

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

Ответ 3

Вы можете просто использовать "default" web.config в качестве своей версии для разработки/отладки, а затем web.release.config, конечно, будет оставаться версией выпуска, поскольку его преобразования применяются при публикации.

Ответ 4

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

Ответ 5

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

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