Jak mogę używać Web.debug.config we wbudowanym serwerze debugera programu Visual Studio?


Odpowiedzi:


92

To znany błąd. Ta funkcja może być teraz używana tylko jako część procesu wdrażania.

https://connect.microsoft.com/VisualStudio/feedback/details/523221/have-web-debug-config-apply-during-development

Proszę, zagłosuj za tym, jeśli to również napotkasz, więc zostanie to naprawione jak najszybciej.


16
Dla przypomnienia, to nie jest błąd, to jest projekt. Te pliki są przeznaczone do pakowania / publikowania. Nie powinno to jednak zniechęcać nikogo do głosowania w tej sprawie.
Ibrahim Hashimi

26
Cóż, dla mnie jest to błąd, w przeciwnym razie jaki jest cel transformacji debugowania / wydania na lokalnym serwerze? Czasami projekty są błędne, co nie znaczy, że jest poprawne :)
Lord of Scripts

4
Problem pojawia się, gdy używasz Github i musisz zignorować plik web.config podczas synchronizacji. Ale to podważa cel posiadania kopii zapasowej - to znaczy, dlatego używam Githuba. Teraz dodaj AppHarbor do scenariusza i musisz obsługiwać dwa typy plików web.config, ponieważ chcesz, aby twoje apikeys były publikowane na Github, więc musisz podstawić wartości w swoich konfiguracjach przed synchronizacją i opublikowaniem. To jest problem. Zapomnij o podstawianiu wartości w konfiguracji i synchronizacji przez pomyłkę i zgadnij co? Twoje apikeys właśnie trafiły do ​​publicznego repozytorium. Ups, co za problem.
David Robbins,

8
Link do MS Connect jest uszkodzony
Michael Freidgeim

17
@LordofScripts: kiedy błąd jest zamykany "zgodnie z projektem" Czasami chcę powiedzieć "oznacza to błąd w twoim projekcie!"
Roy Tinker

34

Jest to całkiem proste i wierz lub nie, wydaje się, że właśnie w ten sposób ma działać VS.

Dodaj następujące wiersze dosłownie bezpośrednio przed zamykającym tagiem „Project” pliku .csproj projektu zawierającego web.config.

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="Transform">
    <MakeDir Directories="obj\$(Configuration)" Condition="!Exists('obj\$(Configuration)')" />
    <TransformXml Source="Web.Config" Transform="Web.$(Configuration).config" Destination="obj\$(Configuration)\Web.config" StackTrace="true" />
</Target>

Umieść następujące wiersze dosłownie w zdarzeniu po kompilacji we właściwościach projektu, który zawiera plik web.config. Zrób to dla każdej konfiguracji kompilacji, dla której chcesz przeprowadzić transformacje.

"$(MSBUILDBINPATH)\msbuild" "$(ProjectPath)" /t:Transform /p:Configuration=$(ConfigurationName);Platform=AnyCPU
xcopy "$(ProjectDir)obj\$(ConfigurationName)\Web.Config" "$(ProjectDir)". /F /R /Y

1
Zalecałbym tylko dodanie podwójnych cudzysłowów wokół $ (ProjectDir) i $ (ProjectPath), aby uniknąć błędów w przypadku, gdy ścieżka projektu zawiera spacje.
Alexander Prokofyev

1
Lepiej jest użyć <Target Name = "BeforeBuild">, jak zasugerowano na stackoverflow.com/a/10506476/52277
Michael Freidgeim,

Jestem w stanie zmusić transformacje do pracy przy użyciu tego podejścia, ale nie mogę osiągnąć moich punktów przerwania. Mam ustawione debugowanie na true, ale nigdy nie trafiłem w punkt przerwania i otrzymuję następujący komunikat „Punkt przerwania nie zostanie obecnie trafiony. Żadne symbole nie zostały załadowane dla tego dokumentu.”. Dzieje się tak tylko w przypadku moich niestandardowych konfiguracji i działa dobrze, jeśli ustawię konfigurację na „Debuguj”. Jakieś pomysły?
mithun_daa

1
Musiałem dodać podwójne cudzysłowy wokół $ (MSBUILDBINPATH), aby to działało, w przeciwnym razie kończy się z kodem 9009
sotn

6
Zauważ, że zastępuje to oryginał Web.config, więc wszystkie twoje transformacje muszą być „idempotentne” (można je ponownie zastosować na wynikach innych transformacji). Uniemożliwi to również zachowanie rozsądku, jeśli umieścisz plik w kontroli źródła (tak jak prawdopodobnie powinieneś). Ogólnie rzecz biorąc, „prosty” hack, który przenosi złożoność / ból na kolejny zestaw problemów. Dobrze, jeśli możesz sobie z tym poradzić „lepiej” tam, źle, jeśli nie. Również rozważyć użycie $ (VisualStudioVersion) zamiast twarde kodowania wersji VS (trzeba będzie zapomnieć, aby go zmienić).
tne

16

Rozwiązałem to w prostszy sposób, dodając to na końcu pliku .csproj, tuż przed tagiem. Jest to podobne do odpowiedzi Keitn, z tą różnicą, że nie używa zdarzenia po kompilacji.

<Target Name="BeforeBuild">
    <TransformXml Source="Web.config" Transform="Web.$(Configuration).config" Destination="Web.config" />
</Target>

3
Potwierdzone, to działa. Ale bądź ostrożny, modyfikuje lokalną kopię pliku Web.config. Więc jeśli używasz transformacji XSLT, takich jak RemoveAttributes, jest to zdecydowanie usunięte! Działa dobrze z SetAttributes
Loul G.

To zrobiło dokładnie to, czego szukałem. Prosto i prosto do celu. Nie wiem, dlaczego wszystkie inne rozwiązania muszą być tak ... złożone.
David Carrigan,

Czy ktoś wie, jak cofnąć tę czynność w sekcji <Target name = "AfterBuild">?
Cameron Belt

1
To powinna być odpowiedź.
Cameron Belt

2

Nie chciałem aktualizować pliku web.config w moim projekcie tylko ten, który trafia do folderu bin, więc oto jak to zrobiłem.

Dodaj następujący kod na końcu .csproj (tuż przed ostatnim znacznikiem zamykającym projektu)

<Target Name="Transform">
    <MakeDir Directories="bin" Condition="!Exists('bin')" />
    <TransformXml Source="Web.Config" Transform="Web.$(Configuration).config" Destination="bin\$(TargetFileName).config" StackTrace="true" />
  </Target>

Następnie dodaj następujący krok po kompilacji

"$(MSBUILDBINPATH)\msbuild" "$(ProjectPath)" /t:Transform /p:Configuration=$(ConfigurationName);Platform=AnyCPU

Oznacza to, że podczas budowania transformacja odbywa się z pliku debug / release config do pliku WebsiteName.Config w wyjściowym katalogu bin, a zatem nie koliduje z głównym web.config w projekcie.


2
To zmienia konfigurację w katalogu bin, niestety ta konfiguracja nigdy nie jest używana. Załadowana konfiguracja to w rzeczywistości plik Web.Config w folderze projektu, a nie ten w katalogu bin.
Mick

2

Po przeczytaniu wielu podobnych postów i problemach z plikami, których nie można nadpisać lub nie można uzyskać dostępu do pliku web.config, ponieważ jest on tylko do odczytu, oto co pracowało dla mnie:

  <Target Name="BeforeBuild" Condition="$(Configuration) == 'MyAltDebugConfiguration'">
    <ItemGroup>
      <OriginalWebConfig Include="$(ProjectDir)Web.config"/>
      <TempWebConfig Include="$(ProjectDir)TempWeb.config"/>
    </ItemGroup>
    <Exec Command="&quot;$(DevEnvDir)tf.exe&quot; checkout &quot;$(ProjectDir)Web.config&quot;" />
    <Copy SourceFiles="@(OriginalWebConfig)" DestinationFiles="@(TempWebConfig)" />
    <TransformXml Source="$(ProjectDir)TempWeb.config"
                            Transform="Web.$(Configuration).config"
                            Destination="Web.config" />
  </Target>

Uwagi:

Działa jako cel BeforeBuild.

Chcę, aby działał tylko w określonej konfiguracji (alternatywnym środowisku debugowania) i dlatego mam parametr Condition. Podczas wdrażania za pośrednictwem sieci Web cel publikacji włącza się i nie potrzebuję tego celu do działania.

Nie chcę pamiętać o sprawdzeniu pliku web.config (tylko po to, aby go cofnąć, gdy skończę), więc sprawdzam web.config przed rozpoczęciem transformacji. Jeśli nie używasz TFS, możesz usunąć ten wiersz.

Ponieważ VS (2010) \ msbuild nie chce puścić źródła web.config, używam pliku tymczasowego (dzięki temu artykułowi za informacje: http://www.diaryofaninja.com/blog/2011/09/ 14 / using-custom-webconfig-transformations-in-msbuild )

Próbowałem dodać polecenie usunięcia TempWeb.config, ale VS \ msbuild nie chce go puścić. Mogę z tym żyć, ponieważ nie jest dodawany do TFS.


Mam ten błąd The command ""C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\tf.exe" checkout "C:\_Code\RTS\SCTimeSheet\Web.config"" exited with code 9009. Jakieś pomysły?
sky91

1

Wiem, że to jest stare, ale mam ten sam problem. Mamy konfiguracje Test, Staging, Live, które zastępują punkty końcowe, parametry połączenia itp. Z domyślnego pliku Web.config

Jednak zrobiłbym następujące rzeczy:

  • Kliknij prawym przyciskiem żądaną konfigurację transformacji (np. Web.Live.config )
  • Kliknij „Podgląd transformacji”
  • Skopiuj wszystko od prawej (tak wygląda plik Web.config z transformacją)
    • CTRL + A + CTRL + C
  • Otwórz plik Web.config (domyślny)
  • Zaznacz wszystko (CTRL + A) i wklej (CTRL + V)
  • Biegać

To nie jest tak wiele kroków i jest to zrobione dość szybko, gdy już to zrozumiesz. Mam nadzieję że to pomoże. :)


Jeśli dobrze zrozumiałem, jest to destrukcyjna zmiana w oryginalnym pliku web.config. W kontekście pytania te kroki musiałyby być wykonywane za każdym razem, gdy uruchamiana jest sesja debugowania.
Red Taz

-1

@ologesa: Twoje rozwiązanie wymaga dostępu do zapisu w oryginalnym pliku Web.config (musisz wyewidencjonować w programie TFS). Lepszym rozwiązaniem jest bezpośrednie wygenerowanie pliku Web.config w folderze bin, tak jak robi to keitn. Kiedy połączymy Keitn i Twoje rozwiązanie, otrzymamy to:

<Target Name="BeforeBuild">
    <Message Text="Transforming Web.config from Web.$(Configuration).config" Importance="high" />
    <MakeDir Directories="bin" Condition="!Exists('bin')" />
    <TransformXml Source="Web.Config" Transform="Web.$(Configuration).config" Destination="bin\$(TargetFileName).config" StackTrace="true" />
</Target>

3
Byłoby miło, ale jak skomentował Mick; ten plik nie jest używany. Jak sprawić, by aplikacja lub usługi IIS używały tego pliku konfiguracyjnego?
HMR
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.