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

Question

Можно создать дубликат:
How can I use Web.debug.config in the built-in visual studio debugger server?

Я хочу использовать преобразование Web.config, который работает отлично подходит для публиковать и для отладки.

Когда я публикую веб-приложение, Visual Studio автоматически преобразует Web.config на основе моей конфигурации currenctbuild. Как я могу сказать Visual Studio делать то же самое, когда я начинаю отладку? При запуске отладки он просто использует файл Web.config по умолчанию без преобразования.

Любая идея?

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

ОК, при том понимании, что 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, потому что они уже имеют четко определенную роль в издательском Pipeline Web, поэтому мы не хотим нарушать это. Поэтому вместо этого мы создадим два новых файла в той же папке, что и проект, и 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, которую я ввожу в процесс пакет/публикацию через атрибут BeforeTargets=”ExcludeFilesFromPackage”. Это необходимо, потому что мы не хотим, чтобы эти файлы включались, когда приложение было упаковано или опубликовано. Так что это действительно все.

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