Używanie różnych Web.config w środowisku programistycznym i produkcyjnym

Potrzebuję użyć innego ciągu połączenia z bazą danych i adresu serwera SMTP w mojej aplikacji ASP.NET, w zależności od tego, czy jest on uruchamiany w środowisku programistycznym lub produkcyjnym.

Aplikacja odczytuje ustawienia z pliku Web.config za pośrednictwem właściwości WebConfigurationManager.AppSettings .

Używam komendy Build / Publish, aby wdrożyć aplikację na serwerze produkcyjnym za pośrednictwem FTP, a następnie ręcznie zastąpić zdalny plik Web.config prawidłowym.

Czy jest to możliwe w jakiś sposób uprościć proces wdrażania? Dzięki!

W Visual Studio 2010 i nowszych wersjach możesz teraz zastosować transformację do pliku web.config w zależności od konfiguracji kompilacji.

Podczas tworzenia pliku web.config możesz rozwinąć plik w eksploratorze rozwiązań, a zobaczysz dwa pliki:

• Web.Debug.Config
• Web.Release.Config

Zawierają kod transformacji, do którego można się przyzwyczaić

• Zmień parametry połączenia
• Usuń dane śledzenia i ustawienia debugowania
• Zarejestruj strony błędów

Aby uzyskać więcej informacji, zobacz Składnia transformacji Web.config dla wdrażania projektu aplikacji sieci Web na MSDN.

Możliwe jest również, choć oficjalnie nieobsługiwane, zastosowanie tego samego rodzaju transformacji do app.configpliku aplikacji innej niż internetowa . Zobacz blog Phila Bolduca, w jaki sposób zmodyfikować plik projektu, aby dodać nowe zadanie do msbuild.

Jest to długotrwała prośba w usłudze Visual Studio Uservoice .

Rozszerzenie dla Visual Studio 2010 i powyżej „ SlowCheetah ” dostępny jest, aby dbać o tworzenie przekształcić do każdego pliku konfiguracyjnego. Począwszy od Visual Studio 2017.3, SlowCheetah został zintegrowany z IDE, a bazą kodu zarządza Microsoft. Ta nowa wersja obsługuje także transformację JSON.

<appSettings>Tag w web.config obsługuje atrybut pliku, który zostanie załadowany zewnętrznego config z jego własnym zestawem klucz / wartość. Zastąpią one wszystkie ustawienia w pliku web.config lub zostaną do nich dodane.

Korzystamy z tego, modyfikując nasz plik web.config w czasie instalacji za pomocą atrybutu pliku odpowiadającego środowisku, w którym instalowana jest witryna. Robimy to za pomocą przełącznika w naszym instalatorze.

na przykład;

<appSettings file=".\EnvironmentSpecificConfigurations\dev.config">

<appSettings file=".\EnvironmentSpecificConfigurations\qa.config">

<appSettings file=".\EnvironmentSpecificConfigurations\production.config">

Uwaga:

• Zmiany w .config określone przez atrybut nie spowodują ponownego uruchomienia procesu roboczego asp.net

Czy zajrzałeś do projektów wdrażania stron internetowych?

http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en

Istnieje również wersja dla VS2005, jeśli nie jesteś w 2008 roku.

Też chciałbym wiedzieć. Pomaga mi to wyodrębnić problem

<connectionStrings configSource = "connectionStrings.config" />

Następnie przechowuję connectionStrings.config, a także „{host} connectionStrings.config”. Nadal jest to problem, ale jeśli zrobisz to dla sekcji różniących się w dwóch środowiskach, możesz wdrożyć i zaktualizować ten sam plik web.config.

(I nie używam VS, btw.)

Używam skryptu budowania NAnt do wdrażania w różnych środowiskach. Mam modyfikować moje pliki konfiguracyjne za pomocą XPath w zależności od miejsca, w którym są wdrażane, a następnie automatycznie umieszcza je w tym środowisku za pomocą Beyond Compare .

Konfiguracja zajmuje minutę lub dwie, ale musisz to zrobić tylko raz. Potem pliki wsadowe przejmują kontrolę, gdy idę po kolejną filiżankę kawy. :)

Oto artykuł na ten temat.

W jednym projekcie, w którym mieliśmy 4 środowiska (programowanie, testowanie, przemieszczanie i produkcja), opracowaliśmy system, w którym aplikacja wybrała odpowiednią konfigurację na podstawie nazwy komputera, na którym została wdrożona.

To działało dla nas, ponieważ:

• administratorzy mogli wdrażać aplikacje bez angażowania programistów (wymaganie) i bez konieczności majstrowania przy plikach konfiguracyjnych (których nienawidzili);
• nazwy maszyn przestrzegane w konwencji. Dopasowaliśmy nazwy przy użyciu wyrażenia regularnego i wdrożyliśmy na wielu komputerach w środowisku; i
• zastosowaliśmy zintegrowane zabezpieczenia ciągów połączeń. Oznacza to, że możemy przechowywać nazwy kont w naszych plikach konfiguracyjnych w czasie projektowania bez ujawniania żadnych haseł.

W tym przypadku działało to dla nas dobrze, ale prawdopodobnie nie działałoby wszędzie.

Pomoże Ci w tym edytor konfiguracji biblioteki Enterprise Library. Pozwala utworzyć podstawowy plik konfiguracyjny, a następnie delty dla każdego środowiska. Następnie możesz połączyć konfigurację podstawową i różnicę, aby utworzyć specyficzny dla środowiska plik web.config. Spójrz na informacje , które poprowadzą Cię przez to lepiej niż ja.

Możesz także uczynić to krokiem po kompilacji. Skonfiguruj nową konfigurację, która jest „Wdróż” oprócz debugowania i wydania, a następnie skopiuj krok po kompilacji na poprawnym pliku web.config.

Używamy automatycznych kompilacji do wszystkich naszych projektów, a wraz z nimi skrypt kompilacji aktualizuje plik web.config, aby wskazywał prawidłową lokalizację. Ale to ci nie pomoże, jeśli robisz wszystko z VS.

Jest to jedna z ogromnych zalet korzystania z pliku machine.config. W mojej ostatniej pracy mieliśmy środowiska programistyczne, testowe i produkcyjne. Możemy użyć pliku machine.config do takich rzeczy jak parametry połączenia (do odpowiedniej maszyny SQL dev / test / prod SQL).

Może to nie być rozwiązaniem dla Ciebie, jeśli nie masz dostępu do rzeczywistej maszyny produkcyjnej (np. Jeśli korzystasz z firmy hostingowej na wspólnym hoście).

Możesz także użyć rozszerzenia „Transformacja konfiguracji” działa tak samo jak „SlowCheetah”,