디버깅을 위해 Visual Studio web.config 변환 사용

디버깅을 위해 Visual Studio web.config 변환 사용

---

가능한 중복 :
내장 Visual Studio 디버거 서버에서 Web.debug.config를 어떻게 사용할 수 있습니까?

디버깅에도 게시 용으로 작동하는 Web.config 변환을 사용하고 싶습니다.

웹 응용 프로그램을 게시하면 Visual Studio는 currenctbuild 구성에 따라 Web.config를 자동으로 변환합니다. 디버깅을 시작할 때 Visual Studio에 동일한 작업을 수행하도록 지시하려면 어떻게해야합니까? 디버그 시작시 단순히 변환없이 기본 Web.config를 사용합니다.

어떤 생각?

---

web.debug.config& web.release.config는 패키지 / 게시에만 해당됨을 이해하고 있습니다. 나는 당신이하려는 일을 가능하게하는 방법을 생각해 냈습니다. http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx 에서 블로그를 작성했습니다 . 다음은 요약입니다.

이제 질문자가 원하는 것을 어떻게 할 수 있는지 살펴 보겠습니다.

요약하자면, 그는 특정 구성을 기반으로 특정 변환을 적용하기를 원합니다 web.config. 따라서 web.config파일을 덮어 쓰기 때문에 파일 을 유지 관리하고 싶지 않습니다 .

따라서 우리가해야 할 일은 새 파일을 만드는 것 web.template.config입니다 web.config. 그런 다음 web.configWindows 탐색기를 사용하여 삭제하십시오 (프로젝트에서 Visual Studio를 삭제하지 않기 때문에 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 (Web Application Projects)를 사용하면 이름이 {ProjectName}.wpp.targetswhere 인 {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>

이것을 조금 설명하겠습니다. Visual Studio에서 응용 프로그램을 디버깅하지 않더라도 빌드시 항상 복사 web.template.config할 CopyWebTemplateConfig 대상을 만들었습니다 web.config.

This is needed because we still need to support the package/publish process of Visual Studio. Then I extended the property PrepareForRunDependsOn to include the UpdateWebConfigBeforeRun target. This property is used to identify the list of targets which needs to be executed before any managed project is run from Visual Studio.

In this target I am using the TransformXml task to transform web.template.config, using the correct web.dev.***.config file. After that your app starts up using the correct web.config based on your build configuration. After that I have another target ExcludeCustomConfigTransformsFiles, which I inject into the package/publish process via the attribute BeforeTargets=”ExcludeFilesFromPackage”. This is needed because we do not want these files to be included when the application is packaged or published. So that is really all there is to it.

To explain the package/publish process a bit more for this scenario. When you package/publish web.debug.config or web.release.config, depending on build configuration, will still be used. But ultimately the file that it is transforming is web.template.config, so you may have to adjust depending on what you have in that file. Questions/Comments?

---

Andrew is on the right path. When you are using this feature here is how it was designed to be used.

web.config This is the config file which developers should use locally. Ideally you should get this to be standardized. For instance you could use localhost for DB strings, and what not. You should strive for this to work on dev machines without changes.

web.debug.config This is the transform that is applied when you publish your application to the development staging environment. This would make changes to the web.config which are required for the target environment.

web.release.config This is the transform that is applied when you publish your application to the "production" environment. Obviously you'll have to be careful with passwords depending on your application/team.

The problem with transforming the web.config that you are currently running is that a transform can perform destructive actions to the web.config. For example it may delete a attributes, delete elements, etc.

---

You could just use the 'default' web.config as your development/debugging version, and then the web.release.config would of course continue to be the release version, since its transforms are applied when you publish.

---

In your debug configuration, add a post-build step, and use it to replace/transform your web.config

---

Although I agree that the simplest approach is usually the best, I can easily imagine a circumstance where for some period of time you want to connect your IDE to a test database instead of your development database. Although you can specify the development connect strings in your default web.config file, it would be really nice to have a Web.Test.config file so that when you swap your build configuration to "Test", you would automatically get the new settings while still in your IDE.

The historical alternative is commenting out one set of connection strings for another, but these new config transforms held out the hope of finally putting a stake in the heart of that ugly practice. Although one default file for development and a transform for release may work much of the time, adding a post-build step to transform the web.config file is the more complete answer in my opinion.

참고URL : https://stackoverflow.com/questions/3922291/use-visual-studio-web-config-transform-for-debugging