Wykorzystanie Visual Studio web.config przekształcić do debugowania

Question

Powiel możliwe:
How can I use Web.debug.config in the built-in visual studio debugger server?

chcę użyć transformacji Web.config, który działa dobrze dla publikuje także do debugowania.

Po opublikowaniu aplikacji internetowej program Visual Studio automatycznie przekształca plik Web.config na podstawie konfiguracji mojego currenctbuild. Jak mogę poinformować program Visual Studio, aby zrobił to samo po uruchomieniu debugowania? Po uruchomieniu debugowania po prostu używa domyślnego pliku Web.config bez transformacji.

Każdy pomysł?

Answer 1

W konfiguracji debugowania, dodać krok po kompilacji i używać go zastąpić/przekształcić swoje web.config

Answer 2

Można po prostu użyć „default” web.config jako wersja rozwojowa/debugowania, a następnie web.release.config będzie oczywiście nadal wersją wydania, ponieważ transformacje są stosowane podczas publikowania.

Answer 3

Chociaż zgadzam się, że najprostsze podejście jest zwykle najlepsze, mogę łatwo wyobrazić sobie sytuację, w której przez pewien okres czasu chcesz połączyć swoje IDE z bazą danych testowych zamiast z bazą danych programowania. Chociaż możesz określić ciągi połączenia programisty w domyślnym pliku web.config, byłoby naprawdę miło mieć plik Web.Test.config, więc gdy zamienisz konfigurację kompilacji na "Test", automatycznie uzyskasz nowe ustawienia podczas gdy jesteś w swoim IDE.

Historyczna alternatywa polega na skomentowaniu jednego zestawu ciągów połączeń dla drugiego, ale te nowe przekształcenia konfiguracji dają nadzieję na ostateczne umieszczenie stawki w sercu tej brzydkiej praktyki. Mimo że jeden domyślny plik do opracowania i transformacja do wydania może działać przez długi czas, dodanie bardziej szczegółowej odpowiedzi do pliku web.config jest, moim zdaniem, bardziej kompletną odpowiedzią.

Answer 4

Andrew jest na dobrej drodze. Gdy korzystasz z tej funkcji, to w jaki sposób został zaprojektowany do użycia.

web.config To jest plik konfiguracyjny, który programiści powinni używać lokalnie. Idealnie powinieneś to zestandaryzować. Na przykład można użyć localhost dla ciągów DB, a co nie. Powinieneś dążyć do tego, aby to działało na komputerach bez zmian.

web.debug.config Jest to transformacja stosowana podczas publikowania aplikacji w środowisku pomostowym programisty. Wprowadziłoby to zmiany w pliku web.config, które są wymagane w środowisku docelowym.

web.release.config Jest to transformacja stosowana podczas publikowania aplikacji w środowisku "produkcyjnym". Oczywiście musisz być ostrożny z hasłami w zależności od aplikacji/zespołu.

Problem z przekształceniem aktualnie używanego pliku web.config polega na tym, że transformacja może wykonywać akcje destrukcyjne w pliku web.config. Na przykład może usunąć atrybuty, usunąć elementy itp.

Answer 5

OK, przy założeniu, że web.debug.config & web.release.config dotyczy tylko pakietu/publikacji. Wymyśliłem sposób, aby umożliwić to, co próbujesz zrobić. Blogowałem o tym pod adresem http://sedodream.com/2010/10/21/ASPNETWebProjectsWebdebugconfigWebreleaseconfig.aspx. Oto podsumowanie.

Zobaczmy teraz, jak możemy włączyć to, co pytający pytający chce zrobić.

Podsumowując, kiedy tworzy konkretną konfigurację, chce zastosować konkretną transformację do web.config. Więc oczywiście nie chcesz zachować pliku web.config, ponieważ zostanie on nadpisany.

Musimy zatem utworzyć nowy plik web.template.config, który jest tylko kopią web.config. Następnie po prostu usuń web.config za pomocą Eksploratora Windows (nie usuwaj przy użyciu Visual Studio, ponieważ nie chcemy go usuwać z projektu).

Uwaga: Jeśli korzystasz z dostawcy kontroli kodu źródłowego zintegrowanego z programem Visual Studio, prawdopodobnie zechcesz usunąć plik web.config ze sterowania źródłowego.

Również z tym nie chcemy korzystać z web.debug.config lub web.release.config, ponieważ mają one już dobrze określoną rolę w gazecie publikowania w Internecie, więc nie chcemy tego przeszkadzać. Dlatego utworzymy dwa nowe pliki w tym samym folderze co projekt i web.template.config, web.dev.debug.config i web.dev.release.config.

Chodzi o to, że będą to transformacje stosowane podczas debugowania lub uruchamiania aplikacji z Visual Studio. Teraz musimy podłączyć się do procesu budowania/pakietowania/publikowania, aby uzyskać to wszystko połączone. W przypadku projektów aplikacji WWW (WAP) istnieje punkt rozszerzenia, w którym można utworzyć plik projektu w tym samym folderze o nazwie {ProjectName}.wpp.targets, gdzie {ProjectName} jest nazwą projektu. Jeśli ten plik znajduje się na dysku w tym samym folderze co WAP, zostanie automatycznie zaimportowany do pliku projektu. Więc stworzyłem ten plik. I umieściłem następującą treść:

<?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> 

Pozwól mi to wyjaśnić. Stworzyłem obiekt CopyWebTemplateConfig, który zawsze kopiuje web.template.config do web.config na kompilacji, nawet jeśli nie debugujesz aplikacji w Visual Studio.

Jest to konieczne, ponieważ wciąż musimy wspierać proces pakowania/publikowania w Visual Studio. Następnie rozszerzyłem właściwość PrepareForRunDependsOn, aby objąć cel o wartości UpdateWebConfigBeforeRun. Ta właściwość służy do identyfikowania listy celów, które muszą zostać wykonane, zanim dowolny zarządzany projekt zostanie uruchomiony z programu Visual Studio.

W tym celu używam zadania TransformXml do transformacji web.template.config, używając poprawnego pliku web.dev.***.config. Następnie aplikacja uruchamia się przy użyciu poprawnej web.config w oparciu o konfigurację kompilacji. Po tym mam kolejny cel ExcludeCustomConfigTransformsFiles, który wprowadzam do procesu pakowania/publikowania za pomocą atrybutu BeforeTargets=”ExcludeFilesFromPackage”. Jest to potrzebne, ponieważ nie chcemy, aby te pliki były dołączane, gdy aplikacja jest pakowana lub publikowana. Więc to naprawdę wszystko.

Aby wyjaśnić proces pakowania/publikowania nieco więcej w tym scenariuszu.Podczas pakowania/publikowania web.debug.config lub web.release.config, w zależności od konfiguracji kompilacji, nadal będzie używany. Ale ostatecznie plik, który się transformuje to web.template.config, więc być może będziesz musiał dostosować w zależności od tego, co masz w tym pliku. Pytania/komentarze?