App.Config Transformation dla projektów, które nie są projektami webowymi w Visual Studio?

Próbowałem kilku rozwiązań i oto najprostsze, które osobiście znalazłem.
Dan wskazał w komentarzach, że oryginalny post należy do Oleg Sych-dzięki, Oleg!

Oto instrukcje:

1. Dodaj plik XML dla każdej konfiguracji do projektu.

Zazwyczaj masz konfiguracje Debug i Release, więc nazwij swoje pliki App.Debug.config i App.Release.config. W moim projekcie stworzyłem konfigurację dla każdego rodzaj środowiska, więc może chcesz eksperymentować z tym.

2. Rozładuj projekt i otwórz .plik csproj do edycji

Visual Studio pozwala na edycję .CSPROJ pliki bezpośrednio w edytorze-wystarczy najpierw rozładować projekt. Następnie kliknij prawym przyciskiem myszy na nim i wybierz Edytuj .csproj .

3. Bind App.*.pliki konfiguracyjne do głównej aplikacji.config

Znajdź sekcję Plik projektu, która zawiera wszystkie App.config i App.*.config referencje. Zauważ, że ich akcje budowania są ustawione na None:

<None Include="App.config" />
<None Include="App.Debug.config" />
<None Include="App.Release.config" />

Najpierw ustaw akcję budowania dla wszystkich na Content.
Następnie wszystkie specyficzne dla konfiguracji pliki zależą od głównej App.config, więc Visual Studio grupuje je tak, jak pliki projektanta i kodu.

Zastąp XML powyżej poniższym:

<Content Include="App.config" />
<Content Include="App.Debug.config" >
  <DependentUpon>App.config</DependentUpon>
</Content>
<Content Include="App.Release.config" >
  <DependentUpon>App.config</DependentUpon>
</Content>

4. Aktywuj magię transformacji

Na końcu pliku po

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

I przed finał

</Project>

Wstaw następujący XML:

  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
  <Target Name="CoreCompile" Condition="exists('app.$(Configuration).config')">
    <!-- Generate transformed app config in the intermediate directory -->
    <TransformXml Source="app.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="app.$(Configuration).config" />
    <!-- Force build process to use the transformed configuration file from now on. -->
    <ItemGroup>
      <AppConfigWithTargetPath Remove="app.config" />
      <AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
        <TargetPath>$(TargetFileName).config</TargetPath>
      </AppConfigWithTargetPath>
    </ItemGroup>
  </Target>

Teraz możesz przeładować projekt, zbudować go i cieszyć się App.config transformacjami!

FYI

Upewnij się, że Twoje pliki App.*.config mają odpowiednią konfigurację w następujący sposób:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
     <!--magic transformations here-->
</configuration>

Innym rozwiązaniem, jakie znalazłem, jest nie używanie przekształceń, ale posiadanie osobnego pliku konfiguracyjnego, np. aplikacji.Uwolnij.config. Następnie dodaj tę linię do pliku csproj.

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
    <AppConfig>App.Release.config</AppConfig>
  </PropertyGroup>

To nie tylko wygeneruje właściwy program myprogram.exe.plik konfiguracyjny ale jeśli używasz projektu instalacji i wdrożenia w Visual Studio do generowania MSI, wymusi to użycie prawidłowego pliku konfiguracyjnego podczas pakowania.

Z mojego doświadczenia wynika, że rzeczy, których potrzebuję, aby były specyficzne dla środowiska, to ciągi połączeń, ustawienia aplikacji i często ustawienia smpt. System config pozwala określić te rzeczy w osobnych plikach. Możesz więc użyć tego w swojej aplikacji.config / web.config:

 <appSettings configSource="appsettings.config" />
 <connectionStrings configSource="connection.config" />
 <system.net>
    <mailSettings>
       <smtp configSource="smtp.config"/>
    </mailSettings>
 </system.net>

To, co zwykle robię, to umieszczanie tych sekcji specyficznych dla konfiguracji w osobnych plikach, w podfolderze o nazwie ConfigFiles(zależy to od katalogu głównego rozwiązania lub na poziomie projektu). Definiuję plik na konfigurację, np. smtp.config.Debugowanie i smtp.config.Uwolnij.

Następnie możesz zdefiniować Zdarzenie pre-build w następujący sposób:

copy $(ProjectDir)ConfigFiles\smtp.config.$(ConfigurationName) $(TargetDir)smtp.config

W rozwijaniu zespołu, możesz to jeszcze poprawić, włączając %COMPUTERNAME% i / lub % USERNAME% do konwencji.

Oczywiście oznacza to, że pliki docelowe (x. config) nie powinny być poddawane kontroli źródła (ponieważ są generowane). Nadal należy dodać je do pliku projektu i ustawić ich Właściwość output type na "copy always" lub "copy if newer" chociaż.

Prosty, rozszerzalny i działa dla wszystkich typów projektów Visual Studio(console, winforms, wpf, web).

Możesz użyć osobnego pliku konfiguracyjnego dla każdej konfiguracji, np. aplikacji.Debugowanie.config, app.Uwolnij.config, a następnie użyj zmiennej konfiguracyjnej w pliku projektu:

<PropertyGroup>
    <AppConfig>App.$(Configuration).config</AppConfig>
</PropertyGroup>

Spowoduje to utworzenie poprawnej nazwy projektu.exe.plik konfiguracyjny w zależności od konfiguracji, w której budujesz.

Zainspirowany Oleg i inni w tym pytaniu, wziąłem rozwiązanie https://stackoverflow.com/a/5109530/2286801 krok dalej, aby włączyć następujące.

• Działa z ClickOnce
• współpracuje z projektami instalacji i wdrożeń w VS 2010
• Działa z VS2010, 2013, 2015(nie testował 2012, chociaż powinien również działać).
• współpracuje z Team Build. (Musisz zainstalować a) Visual Studio lub B) Microsoft.Www.Wydawnictwo.cele i Microsoft.Www.Wydawnictwo.Zadania.dll)

To rozwiązanie działa poprzez wykonanie aplikacji.konfiguracja przed aplikacją.config jest odwoływany po raz pierwszy w procesie MSBuild. Wykorzystuje zewnętrzny plik docelowy do łatwiejszego zarządzania wieloma projektami.

Instrukcje:

Podobne kroki do innego rozwiązania. Zacytowałem to, co pozostaje takie samo i dodałem to dla kompletności i łatwiejszego porównania.

0. Dodaj nowy plik do projektu nazywa się AppConfigTransformation.cele

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- Transform the app config per project configuration.-->
  <PropertyGroup>
    <!-- This ensures compatibility across multiple versions of Visual Studio when using a solution file.
         However, when using MSBuild directly you may need to override this property to 11.0 or 12.0 
         accordingly as part of the MSBuild script, ie /p:VisualStudioVersion=11.0;
         See http://blogs.msdn.com/b/webdev/archive/2012/08/22/visual-studio-project-compatability-and-visualstudioversion.aspx -->
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  </PropertyGroup>

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.targets" />

  <Target Name="SetTransformAppConfigDestination" BeforeTargets="PrepareForBuild" 
          Condition="exists('app.$(Configuration).config')">
    <PropertyGroup>
      <!-- Force build process to use the transformed configuration file from now on. -->
      <AppConfig>$(IntermediateOutputPath)$(TargetFileName).config</AppConfig>
    </PropertyGroup>
    <Message Text="AppConfig transformation destination: = $(AppConfig)" />
  </Target>

  <!-- Transform the app.config after the prepare for build completes. -->
  <Target Name="TransformAppConfig" AfterTargets="PrepareForBuild" Condition="exists('app.$(Configuration).config')">
    <!-- Generate transformed app config in the intermediate directory -->
    <TransformXml Source="app.config" Destination="$(AppConfig)" Transform="app.$(Configuration).config" />
  </Target>

</Project>

1. Dodaj plik XML dla każdej konfiguracji do projektu.

Zazwyczaj masz konfiguracje debugowania i Wydania, więc nazwij swoje pliki aplikacją.Debugowanie.config i App.Uwolnij.config. W moim projekcie stworzyłem konfigurację dla każdego rodzaju środowiska, więc możesz chcieć z tym eksperymentować.

2. Rozładuj projekt i otwórz .plik csproj do edycji

Visual Studio umożliwia edycję .csproj bezpośrednio w edytorze-wystarczy najpierw rozładować projekt. Następnie kliknij go prawym przyciskiem myszy i wybierz Edytuj .csproj.

3. Bind App.*.pliki konfiguracyjne do głównej aplikacji.config

Znajdź sekcję Plik projektu, która zawiera wszystkie aplikacje.config i App.*.Config odwołuje się i zastąpić w następujący sposób. Zauważysz, że używamy None zamiast treści.

<ItemGroup>
  <None Include="app.config"/>
  <None Include="app.Production.config">
    <DependentUpon>app.config</DependentUpon>
  </None>
  <None Include="app.QA.config">
    <DependentUpon>app.config</DependentUpon>
  </None>
  <None Include="app.Development.config">
    <DependentUpon>app.config</DependentUpon>
  </None>
</ItemGroup>

4. Aktywuj magię transformacji

In the end of file after

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

I przed finałem

</Project>

Wstaw następujący XML:

<Import Project="AppConfigTransformation.targets" />

Napisałem ładne rozszerzenie do automatyzacji aplikacji.transformacja konfiguracyjna jak ta wbudowana w projekt aplikacji webowej transformacja konfiguracyjna

Największą zaletą tego rozszerzenia jest to, że nie trzeba go instalować na wszystkich maszynach kompilacyjnych

Natknąłem się na poniższy artykuł, który wygląda nieco prościej, ale sam nie próbowałem.

Http://fknut.blogspot.com/2009/11/appconfig-transformation-with-new.html

Istnieje również prośba o funkcję na MS Connect, która może być warta głosowania, więc zostanie ona uwzględniona w następnej wersji SP lub.

Https://connect.microsoft.com/VisualStudio/feedback/details/564414

Rozwiązuję ten problem za pomocą tego narzędzia http://ctt.codeplex.com / . używam go ze skryptem CCNet/nant do tworzenia pakietów.

Tylko mała Poprawa do rozwiązania, które wydaje się być teraz wszędzie:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />

• to znaczy, chyba że planujesz pozostać z aktualną wersją VS na zawsze

Więc zdecydowałem się na nieco inne podejście. Śledziłem kroki dana przez krok 3, ale dodałem inny plik: App.Baza.Config. Ten plik zawiera ustawienia konfiguracji, które chcesz w każdej wygenerowanej aplikacji.Config. Następnie używam BeforeBuild (z dodatkiem TransformXml), aby przekształcić bieżącą konfigurację z podstawowym config do aplikacji.config. Następnie proces budowania wykorzystuje przekształconą aplikację.config jak zwykle. Jednak jedną z przykrości jest to, że chcesz wykluczyć ciągle zmieniająca się aplikacja.config z kontroli źródła później, ale inne pliki konfiguracyjne są teraz zależne od niego.

  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
  <Target Name="BeforeBuild" Condition="exists('app.$(Configuration).config')">
    <TransformXml Source="App.Base.config" Transform="App.$(Configuration).config" Destination="App.config" />
  </Target>

Stworzyłem kolejną alternatywę dla tej zamieszczonej przez Vishal Joshi gdzie wymóg zmiany akcji build na Zawartość usunięto, a także zaimplementowano podstawową obsługę wdrażania ClickOnce. Mówię basic, bo nie testowałem go dokładnie, ale powinien działać w typowym scenariuszu wdrażania ClickOnce.

Rozwiązanie składa się z pojedynczego projektu MSBuild, który po zaimportowaniu do istniejącego projektu aplikacji windows (*.csproj) rozszerza budowę proces do kontemplacji app.Config transformation.

Możesz przeczytać bardziej szczegółowe wyjaśnienie w Visual Studio App.Config XML Transformation i plik projektu MSBuild można pobrać z GitHub.

Jeśli używasz TFS online (Wersja w chmurze) i chcesz przekształcić aplikację.Config w projekcie można wykonać następujące czynności bez instalowania żadnych dodatkowych narzędzi. Od VS = > rozładuj projekt = > Edytuj plik projektu = > przejdź do dolnej części pliku i dodaj:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild" Condition="Exists('App.$(Configuration).config')">
<TransformXml Source="App.config" Transform="App.$(Configuration).config" Destination="$(OutDir)\$(AssemblyName).dll.config" />

AssemblyFile i Destination działa do użytku lokalnego i serwera TFS online(Cloud).

Zainstaluj "Configuration Transform Tool" w Visual Studio z Marketplace i uruchom ponownie VS. będziesz mógł zobaczyć podgląd menu transform dla aplikacji.config również.

Https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform

Proponowane rozwiązanie nie będzie działać, gdy biblioteka klasy z plikiem konfiguracyjnym jest odwołana z innego projektu(w moim przypadku była to biblioteka projektu Azure worker). Nie skopiuje poprawnego przekształconego pliku z folderu obj do folderu bin\##configuration-name##. Aby to działało z minimalnymi zmianami, musisz zmienić cel AfterCompile na BeforeCompile:

<Target Name="BeforeCompile" Condition="exists('app.$(Configuration).config')">