Udostępnij za pośrednictwem

Typowe różnice konfiguracji między środowiskami deweloperskim i produkcyjnym (C#)

  • Artykuł

Autor : Scott Mitchell

Pobierz plik PDF

We wcześniejszych samouczkach wdrożyliśmy naszą witrynę internetową, kopiując wszystkie odpowiednie pliki ze środowiska deweloperskiego do środowiska produkcyjnego. Nie jest jednak rzadkością, że istnieją różnice konfiguracji między środowiskami, co wymaga, aby każde środowisko miało unikatowy plik Web.config. Ten samouczek analizuje typowe różnice konfiguracji i analizuje strategie obsługi oddzielnych informacji o konfiguracji.

Wprowadzenie

W dwóch ostatnich samouczkach przedstawiono wdrażanie prostej aplikacji internetowej. W samouczku Wdrażanie witryny przy użyciu klienta FTP pokazano, jak używać autonomicznego klienta FTP do kopiowania niezbędnych plików ze środowiska deweloperskiego do środowiska produkcyjnego. W poprzednim samouczku Wdrażanie witryny przy użyciu programu Visual Studio przyjrzeliśmy się wdrożeniu przy użyciu narzędzia kopiuj witrynę sieci Web programu Visual Studio i opcji Publikuj. W obu samouczkach każdy plik w środowisku produkcyjnym był kopią pliku w środowisku deweloperskim. Nie jest jednak rzadkością, że pliki konfiguracji w środowisku produkcyjnym różnią się od plików w środowisku deweloperskim. Konfiguracja aplikacji internetowej jest przechowywana w Web.config pliku i zwykle zawiera informacje o zasobach zewnętrznych, takich jak baza danych, internet i serwery poczty e-mail. Określa również zachowanie aplikacji w pewnych sytuacjach, na przykład sposób działania, który należy wykonać, gdy wystąpi nieobsługiwany wyjątek.

Podczas wdrażania aplikacji internetowej ważne jest, aby prawidłowe informacje o konfiguracji trafiły do środowiska produkcyjnego. W większości przypadków Web.config nie można skopiować pliku w środowisku deweloperskim do środowiska produkcyjnego. Zamiast tego należy przekazać dostosowaną wersję programu do środowiska produkcyjnego Web.config . W tym samouczku krótko omówiono niektóre z bardziej typowych różnic w konfiguracji; Zawiera również podsumowanie niektórych technik obsługi różnych informacji o konfiguracji między środowiskami.

Typowe różnice konfiguracji między środowiskami deweloperskimi i produkcyjnymi

Plik Web.config zawiera asortyment informacji o konfiguracji dla aplikacji ASP.NET. Niektóre z tych informacji o konfiguracji są takie same niezależnie od środowiska. Na przykład ustawienia uwierzytelniania i reguły autoryzacji adresów URL określone w Web.config plikach <authentication> i <authorization> elementy są zwykle takie same niezależnie od środowiska. Jednak inne informacje o konfiguracji — takie jak informacje o zasobach zewnętrznych — zwykle różnią się w zależności od środowiska.

Parametry połączeń bazy danych są doskonałym przykładem informacji o konfiguracji, które różnią się w zależności od środowiska. Gdy aplikacja internetowa komunikuje się z serwerem bazy danych, musi najpierw nawiązać połączenie i to jest osiągane za pośrednictwem parametry połączenia. Chociaż istnieje możliwość zakodowania bazy danych parametry połączenia bezpośrednio na stronach internetowych lub w kodzie, który łączy się z bazą danych, najlepiej jest umieścić go Web.config<connectionStrings> jako element, tak aby informacje o parametry połączenia mieściły się w jednej, scentralizowanej lokalizacji. Często inna baza danych jest używana podczas opracowywania niż jest używana w środowisku produkcyjnym; w związku z tym informacje parametry połączenia muszą być unikatowe dla każdego środowiska.

Uwaga

W przyszłych samouczkach omówiono wdrażanie aplikacji opartych na danych. W tym momencie zapoznamy się z specyfiką sposobu przechowywania parametrów połączenia bazy danych w pliku konfiguracji.

Zamierzone zachowanie środowisk deweloperskich i produkcyjnych znacznie się różni. Aplikacja internetowa w środowisku deweloperów jest tworzona, testowana i debugowana przez małą grupę deweloperów. W środowisku produkcyjnym, które ta sama aplikacja jest odwiedzana przez wielu różnych równoczesnych użytkowników. ASP.NET zawiera szereg funkcji, które ułatwiają deweloperom testowanie i debugowanie aplikacji, ale te funkcje powinny być wyłączone ze względu na wydajność i bezpieczeństwo w środowisku produkcyjnym. Przyjrzyjmy się kilku takim ustawiom konfiguracji.

Ustawienia konfiguracji wpływające na wydajność

Gdy strona ASP.NET jest odwiedzana po raz pierwszy (lub po raz pierwszy po jej zmianie), jej deklaratywne znaczniki muszą zostać przekonwertowane na klasę, a ta klasa musi zostać skompilowana. Jeśli aplikacja internetowa używa automatycznej kompilacji, należy również skompilować klasę za kodem strony. Można skonfigurować asortyment opcji kompilacji za pomocą Web.config elementu pliku<compilation>.

Atrybut debugowania jest jednym z najważniejszych atrybutów w elemecie <compilation> . debug Jeśli atrybut jest ustawiony na wartość "true", skompilowane zestawy zawierają symbole debugowania, które są potrzebne podczas debugowania aplikacji w programie Visual Studio. Symbole debugowania zwiększają jednak rozmiar zestawu i nakładają dodatkowe wymagania dotyczące pamięci podczas uruchamiania kodu. Ponadto gdy debug atrybut jest ustawiony na wartość "true", każda zawartość zwracana przez WebResource.axd program nie jest buforowana, co oznacza, że za każdym razem, gdy użytkownik odwiedza stronę, będzie musiał ponownie pobrać zawartość statyczną zwróconą przez WebResource.axdprogram .

Uwaga

WebResource.axd to wbudowana procedura obsługi HTTP wprowadzona w ASP.NET 2.0, która służy do pobierania zasobów osadzonych, takich jak pliki skryptów, obrazy, pliki CSS i inna zawartość. Aby uzyskać więcej informacji na WebResource.axd temat sposobu działania i sposobu używania go do uzyskiwania dostępu do osadzonych zasobów z niestandardowych kontrolek serwera, zobacz Uzyskiwanie dostępu do zasobów osadzonych za pośrednictwem adresu URL przy użyciu adresu URL.WebResource.axd

Atrybut <compilation> elementu debug jest zwykle ustawiony na wartość "true" w środowisku deweloperskim. W rzeczywistości ten atrybut musi być ustawiony na wartość "true", aby debugować aplikację internetową; Jeśli spróbujesz debugować aplikację ASP.NET z programu Visual Studio, a debug atrybut jest ustawiony na wartość "false", program Visual Studio wyświetli komunikat wyjaśniający, że nie można debugować aplikacji, dopóki debug atrybut nie zostanie ustawiony na wartość "true" i zaoferuje wprowadzenie tej zmiany.

Nigdy nie należy mieć atrybutu ustawionego debug na wartość "true" w środowisku produkcyjnym ze względu na jego wpływ na wydajność. Aby zapoznać się z bardziej szczegółowym omówieniem tego tematu, zapoznaj się z wpisem w blogu Scotta Guthrie'a, Don't Run Production ASP.NET Applications With Enabled (Nie uruchamiaj aplikacji produkcyjnych ASP.NET z włączoną obsługądebug="true").

Błędy niestandardowe i śledzenie

Gdy w aplikacji ASP.NET wystąpi nieobsługiwany wyjątek, następuje bąbelek do środowiska uruchomieniowego, w którym następuje jedna z trzech rzeczy:

  • Zostanie wyświetlony ogólny komunikat o błędzie środowiska uruchomieniowego. Ta strona informuje użytkownika o błędzie w czasie wykonywania, ale nie podaje żadnych szczegółów dotyczących błędu.
  • Zostanie wyświetlony komunikat ze szczegółami wyjątku zawierający informacje o wyjątku, który właśnie został zgłoszony.
  • Zostanie wyświetlona niestandardowa strona błędu, która jest utworzoną stroną ASP.NET, która wyświetla dowolny komunikat.

To, co dzieje się w obliczu nieobsługiwanego wyjątku, zależy od Web.config sekcji pliku<customErrors>.

Podczas tworzenia i testowania aplikacji pomaga wyświetlić szczegóły każdego wyjątku w przeglądarce. Jednak wyświetlanie szczegółów wyjątku w aplikacji w środowisku produkcyjnym jest potencjalnym zagrożeniem bezpieczeństwa. Co więcej, jest to niepochlebne i sprawia, że witryna internetowa wygląda nieprofesjonalnie. W idealnym przypadku w przypadku nieobsługiwanego wyjątku aplikacja internetowa w środowisku deweloperskim będzie wyświetlać szczegóły wyjątku, podczas gdy ta sama aplikacja w środowisku produkcyjnym będzie wyświetlać niestandardową stronę błędu.

Uwaga

<customErrors> Domyślne ustawienie sekcji pokazuje komunikat szczegółów wyjątku tylko wtedy, gdy strona jest odwiedzana za pośrednictwem hosta lokalnego i wyświetla ogólną stronę błędu środowiska uruchomieniowego w przeciwnym razie. Nie jest to idealne rozwiązanie, ale zapewnia, że domyślne zachowanie nie ujawnia szczegółów wyjątku dla osób odwiedzających nielokalnych. W przyszłym samouczku bardziej szczegółowo omówiono <customErrors> sekcję i przedstawiono sposób wyświetlania niestandardowej strony błędu w przypadku wystąpienia błędu w środowisku produkcyjnym.

Inną funkcją ASP.NET, która jest przydatna podczas opracowywania, jest śledzenie. Śledzenie, jeśli jest włączone, rejestruje informacje o każdym żądaniu przychodzącym i udostępnia specjalną stronę internetową, Trace.axd, do wyświetlania najnowszych szczegółów żądania. Śledzenie można włączyć i skonfigurować za pomocą elementu w elemecie <trace>Web.config.

Jeśli włączysz śledzenie, upewnij się, że jest ona wyłączona w środowisku produkcyjnym. Ponieważ informacje śledzenia obejmują pliki cookie, dane sesji i inne potencjalnie poufne informacje, ważne jest wyłączenie śledzenia w środowisku produkcyjnym. Dobrą wiadomością jest to, że domyślnie śledzenie jest wyłączone, a Trace.axd plik jest dostępny tylko za pośrednictwem hosta lokalnego. Jeśli zmienisz te ustawienia domyślne podczas programowania, upewnij się, że są one wyłączone w środowisku produkcyjnym.

Techniki obsługi oddzielnych informacji o konfiguracji

Posiadanie różnych ustawień konfiguracji w środowiskach deweloperskich i produkcyjnych komplikuje proces wdrażania. W poprzednich dwóch samouczkach proces wdrażania obejmował kopiowanie wszystkich niezbędnych plików z programowania do środowiska produkcyjnego, ale takie podejście działa tylko wtedy, gdy informacje o konfiguracji są takie same w obu środowiskach. Istnieje wiele technik wdrażania aplikacji z różnymi informacjami o konfiguracji. Katalogujmy niektóre z tych opcji dla hostowanych aplikacji internetowych.

Ręczne wdrażanie pliku konfiguracji środowiska produkcyjnego

Najprostszym podejściem jest utrzymanie dwóch wersji Web.config pliku: jednej dla środowiska deweloperskiego i jednej dla środowiska produkcyjnego. Wdrożenie lokacji w środowisku produkcyjnym wiąże się z kopiowaniem wszystkich plików na serwer produkcyjny w środowisku deweloperskim z wyjątkiemWeb.config pliku . Zamiast tego plik specyficzny dla Web.config środowiska produkcyjnego zostanie skopiowany do środowiska produkcyjnego.

Takie podejście nie jest bardzo zaawansowane, ale jest łatwe do zaimplementowania, ponieważ informacje o konfiguracji zmieniają się rzadko. Działa najlepiej w przypadku aplikacji z małym zespołem deweloperów, które są hostowane na jednym serwerze internetowym i których informacje o konfiguracji są rzadko zmieniane. Jest to najbardziej opłacalne podczas ręcznego wdrażania plików aplikacji przy użyciu autonomicznego klienta FTP. W przypadku korzystania z narzędzia do kopiowania witryny sieci Web programu Visual Studio lub opcji Publikuj należy najpierw zamienić plik specyficzny dla wdrożenia na plik specyficzny dla Web.config środowiska produkcyjnego przed wdrożeniem, a następnie zamienić je z powrotem po zakończeniu wdrażania.

Zmienianie konfiguracji podczas procesu kompilacji lub wdrażania

Dyskusje do tej pory zakładały proces kompilacji i wdrażania ad hoc. Wiele większych projektów oprogramowania ma bardziej sformalizowane procesy, które korzystają z narzędzi open source, home-grown lub innych firm. W przypadku takich projektów można prawdopodobnie dostosować proces kompilacji lub wdrażania, aby odpowiednio zmodyfikować informacje o konfiguracji przed wypchnięciem do środowiska produkcyjnego. Jeśli tworzysz aplikację internetową przy użyciu programu MSBuild, NAnt lub innego narzędzia kompilacji, prawdopodobnie możesz dodać krok kompilacji, aby zmodyfikować plik w Web.config celu uwzględnienia ustawień specyficznych dla środowiska produkcyjnego. Przepływ pracy wdrażania może też programowo nawiązać połączenie z serwerem kontroli źródła i pobrać odpowiedni Web.config plik.

Rzeczywiste podejście do pobierania odpowiednich informacji o konfiguracji do środowiska produkcyjnego różni się w zależności od narzędzi i przepływu pracy. W związku z tym nie będziemy zagłębiać się w ten temat. Jeśli używasz popularnego narzędzia kompilacji, takiego jak MSBuild lub NAnt, możesz znaleźć artykuły dotyczące wdrażania i samouczki specyficzne dla tych narzędzi za pośrednictwem wyszukiwania w Internecie.

Zarządzanie różnicami konfiguracji za pośrednictwem projektu wdrażania w Internecie Add-In

W 2006 roku firma Microsoft wydała projekt tworzenia aplikacji internetowych Add-In dla programu Visual Studio 2005. W 2008 r. wydano Add-In dla programu Visual Studio 2008. Ta Add-In umożliwia deweloperom ASP.NET utworzenie oddzielnego projektu wdrażania sieci Web wraz z projektem aplikacji internetowej, który podczas kompilowania jawnie kompiluje aplikację internetową i kopiuje pliki do wdrożenia w lokalnym katalogu wyjściowym. Projekt aplikacji internetowej używa programu MSBuild w tle.

Domyślnie plik środowiska Web.config projektowego jest kopiowany do katalogu wyjściowego, ale można skonfigurować projekt wdrażania w sieci Web w celu dostosowania

informacje o konfiguracji, które są kopiowane do tego katalogu w następujący sposób:

  • Za pomocą Web.config zamiany sekcji pliku, w której należy określić sekcję do zastąpienia i plik XML zawierający tekst zastępczy.
  • Dostarczając ścieżkę do zewnętrznego pliku źródłowego konfiguracji. Po wybraniu tej opcji projekt wdrażania sieci Web kopiuje określony Web.config plik do katalogu wyjściowego (zamiast Web.config pliku używanego w środowisku projektowym).
  • Dodając reguły niestandardowe do pliku MSBuild używanego przez projekt wdrażania sieci Web.

Aby wdrożyć aplikację internetową, skompiluj projekt wdrażania sieci Web, a następnie skopiuj pliki z folderu wyjściowego projektu do środowiska produkcyjnego.

Aby dowiedzieć się więcej na temat korzystania z projektu wdrażania w Sieci Web, zapoznaj się z artykułem Dotyczącym projektów wdrażania w Sieci Web z kwietnia 2007 r. dotyczącym magazynu MSDN Lub zapoznaj się z linkami w sekcji Dalsze informacje na końcu tego samouczka.

Uwaga

Nie można użyć projektu wdrażania w Internecie z visual Web Developer, ponieważ projekt wdrażania w Internecie jest implementowany jako program Visual Studio Add-In, a wersje Visual Studio Express (w tym Visual Web Developer) nie obsługują dodatków.

Podsumowanie

Zasoby zewnętrzne i zachowanie aplikacji internetowej w środowisku deweloperskim są zwykle inne niż w przypadku, gdy ta sama aplikacja jest w środowisku produkcyjnym. Na przykład parametry połączenia bazy danych, opcje kompilacji i zachowanie, gdy wystąpi nieobsługiwany wyjątek, często różnią się między środowiskami. Proces wdrażania musi uwzględniać te różnice. Jak omówiono w tym samouczku, najprostszym podejściem jest ręczne skopiowanie alternatywnego pliku konfiguracji do środowiska produkcyjnego. Bardziej eleganckie rozwiązania są możliwe w przypadku korzystania z projektu wdrażania sieci Web Add-In lub w bardziej sformalizowanym procesie kompilacji lub wdrażania, który może pomieścić takie dostosowania.

Szczęśliwe programowanie!

Dalsze informacje

Aby uzyskać więcej informacji na temat tematów omówionych w tym samouczku, zapoznaj się z następującymi zasobami:

WsteczDalej