Jak warunkowo wdrożyć plik app.config na podstawie konfiguracji kompilacji?

Question

Mam trzy niestandardowe konfiguracje kompilacji {Dev, Qs, Prd}. Mam więc trzy konfiguracje aplikacji {Dev.config, Qs.config, Prd.config}. Wiem, jak edytować plik .csproj, aby wyprowadzić poprawny plik na podstawie bieżącej konfiguracji kompilacji.

<Target Name="AfterBuild"> 
    <Delete Files="$(TargetDir)$(TargetFileName).config" /> 
    <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" /> 
</Target> 

Moim problemem jest to, że trzeba mieć sześć konfiguracje budować {Dev, Qs, Prd} X {Debug Release}. Muszę obsługiwać ustawienia debugowania i wydania (optymalizacje, pdb itp.) Dla każdego środowiska. Jednak wartości konfiguracyjne aplikacji nie zmieniają się między debugowaniem/wydaniem.

Jak zachować ogólny charakter skryptu budowy i używać tylko trzech konfiguracji aplikacji? Nie chcę sztywnego kodowania zbyt wielu łańcuchów warunkowych.

Answer 1

Coś wzdłuż linii

<PropertyGroup Condition="'$(Configuration)'=='Dev_Debug' OR '$(Configuration)'=='Dev_Release'" > 
    <CfgFileName>Dev</CfgFileName> 
</PropertyGroup> 
<!-- similar for Qs & Prd --> 
<Target ...>...$(CfgFileName).config... 

Answer 2

ostatnie rozwiązanie I jak stosować się do stworzenia 6 konfiguracyjne aplikacji, jeden za konfigurację licznika

{Dev_Debug.config, Dev_Release.config, Qs_Debug.config, ..., Prd_Release.config}.

Chociaż przy takiej konfiguracji mogłem zachować ogólny skrypt kompilacji, nie używając żadnych łańcuchów warunkowych.

Answer 3

I sugerują, że Twoje pytanie ujawnia, że ​​przerosły app.config --it czas, aby przenieść się do lepszego rozwiązania, a do rozpoczęcia adresowania niektórych zagadnień pokrewnych.

Po pierwsze, NIGDY nie należy automatycznie wdrażać pliku konfiguracyjnego do produkcji i należy oczekiwać, że personel obsługi operacji zdecydowanie odrzuci wszelkie próby wykonania tego. Oczywiście, jeśli jesteś personelem wsparcia operacji, powinieneś go odrzucić sam. Zamiast tego, twoje wydanie powinno zawierać pewne instrukcje ręcznego aktualizowania pliku konfiguracyjnego, z próbką dla ilustracji. Konfiguracja produkcji jest zbyt ważna dla mniejszych miar, chyba że po prostu nie doceniasz swojego systemu produkcyjnego.

Podobnie do testów i innych środowisk, ale w mniejszym stopniu, więc naprawdę potrzebujesz tylko swojego app.config zapełnionego do własnych prac programistycznych.

Opcją jest osadzenie wielu konfiguracji w pojedynczym app.config, co jest uzasadnione w przypadku małych, stosunkowo nieistotnych aplikacji lub we wczesnych etapach rozwoju/wydania. Na przykład utwórz ustawienie konfiguracyjne o nazwie podobnej do target-env, które zawiera wartość, której używasz w kodzie, aby wybrać inne ustawienia konfiguracji, na przykład poprzez dodanie wartości do klawiszy innych ustawień konfiguracji.

Mam pierwszeństwo przed przejściem pod numer app.config lub użycie go w minimalnym zakresie. W tym przypadku wolę umieścić w pliku tylko tyle danych konfiguracyjnych, aby umożliwić aplikacji/systemowi połączenie się z jej bazą danych, a następnie umieścić pozostałe szczegóły konfiguracji w specjalnej tabeli bazy danych do tego celu. Ma to wiele zalet, takich jak tworzenie bazy danych "świadomych" tego, jakie środowisko reprezentuje (programista, test, produkcja itp.) Oraz utrzymywanie konfiguracji i innych danych razem. Pakiet wdrożeniowy może wtedy być właściwie głupi, jeśli chodzi o konfiguracje i różnice środowiskowe - kod po prostu uzyskuje dostęp do danych konfiguracyjnych i działa odpowiednio, więc ten sam pakiet wdrożeniowy jest dobry dla każdego środowiska.

Jednak kluczowym czynnikiem sukcesu takiego podejścia jest to, że kod aplikacji musi "wiedzieć", czego oczekuje od konfiguracji i musi "wiedzieć", aby odrzucić niewłaściwą/niekompletną konfigurację. Tu należy spędzić czas, nie próbując obejść granic app.config.

Zazwyczaj oznacza to utworzenie własnej klasy w celu uzyskania dostępu do danych konfiguracyjnych, a następnie użycie tej klasy w całej aplikacji. Daje to również wiele innych korzyści, takich jak dane konfiguracyjne o silnym typie: zamiast String, należy zwrócić wartość DateTime lub Url, lub Integer lub Currency lub inną najlepiej dopasowaną do danych konfiguracyjnych i aplikacji.

Answer 4

Naprawiliśmy to za pomocą opcji Wybierz element w pliku csproj. Mamy kilka różnych konfiguracji, więc wszystko, co robimy, to upuszczenie tego bloku do pliku proj i możesz użyć VS's Configuration, aby ci pomóc. Chcę powtórzyć porady Roba, aby przenieść przekazany plik app.config. Od pewnego czasu poruszam się w tym kierunku.

<Choose> 
<When Condition=" '$(Configuration)' == 'Debug' "> 
    <ItemGroup> 
    <None Include="App.config" /> 
    <None Include="Release\App.config" /> 
    </ItemGroup> 
</When> 
<Otherwise> 
    <ItemGroup> 
    <None Include="Release\App.config"> 
     <Link>App.config</Link> 
    </None> 
    </ItemGroup> 
</Otherwise> 

Answer 5

Oto miły Discussion at scott Hanselmans o automatyzację wielu konfiguracji.

W sekcji komentarzy jest kilka alternatywnych rozwiązań. Niektóre interesujące, jak praca z deltą plików konfiguracyjnych. Niektóre z nich przypominają różne pliki konfiguracyjne dla różnych środowisk.

Answer 6

Co powiesz na używanie serwera kompilacji?
Dawno nie pracowałem w .NET, ale czy nie możesz używać serwera Hudson (podobnego do) do zarządzania konfiguracjami kompilacji? Czy to nie jest łatwiejsze?
A co z NAnt? Czy to nie pasuje do twoich potrzeb?

Answer 7

brzmi jak jest to bardziej "nowoczesne" rozwiązania (Dostępny od VS2010) http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx