Najlepszy sposób przełączania konfiguracji między środowiskami programowania/UAT/Prod w ASP.NET?

Question

Muszę przełączać się między 3 różnymi środowiskami podczas opracowywania mojej aplikacji internetowej - Rozwój, UAT i Prod. Mam różne połączenia z bazą danych w moich plikach konfiguracyjnych dla wszystkich 3. Widziałem przełączanie tych ustawień ręcznie przez zmianę wszystkich referencji, a następnie przebudowanie rozwiązania, a także za pomocą dyrektyw preprocesora. Czy istnieje prosty sposób na zrobienie tego w oparciu o pewną zmienną, tak aby konfiguracja nie musiała być zmieniana przy każdorazowym wdrażaniu w nowym środowisku?

Answer 1

Wydaje mi się, że można korzystać z Visual Studio 2005 Web Deployment Project s.

Dzięki temu możesz nakazać aktualizację/modyfikację sekcji pliku web.config w zależności od konfiguracji kompilacji.

Aby uzyskać szybki przegląd/próbkę, zobacz this blog entry from Scott Gu.

Answer 2

Scott Hanselman zasugerował jeden sposób, aby to zrobić:

http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx

Answer 3

Przyjąłem Jean Paul Boodhoo Method zmieniających się konfiguracji. Ogólną ideą jest posiadanie jednego lub więcej TOKENIZOWANYCH plików konfiguracyjnych TEMPLATE zamiast samych plików konfiguracyjnych. Następnie masz zadanie skryptu budowania, które zastępuje tokeny wartościami z POJEDYNCZEGO pliku właściwości lokalnych. Ten plik właściwości zawiera wszystkie różnice w konfiguracji i jest unikalny na kopię roboczą.

Ten system sprawdził się doskonale i początkowo konfiguracja jest łatwa w zarządzaniu zmianami środowiska.

Answer 4

Jestem wielkim fanem używając MSBuild, w szczególności zadań MSBuild Wspólnoty (http://msbuildtasks.tigris.org/) i nie jest zadaniem XSLT do przekształcenia web.config z odpowiednimi ustawieniami ciąg połączenia, itp

trzymam zadania te poręczne:

<Target Name="Configs"> 
<Xslt RootTag="" Inputs="web.config" Output="Web.$(COMPUTERNAME).config" Xsl="web.config.$(COMPUTERNAME).xslt" Condition="Exists('web.config.$(COMPUTERNAME).xslt')" /> 

Oczywiście nie jest to 100%, co jesteś po, to tak każdy dev może mieć własne web.c onfig.

Ale nie ma powodu, dla którego nie można zastosować powyższej zasady, aby mieć wiele konfiguracji kompilacji, która stosuje odpowiedni XSLT.

Moja XSLT wygląda następująco:

<?xml version="1.0" encoding="utf-8"?> 

<!-- Dev --> 
<xsl:template match="/configuration/connectionStrings/add[@name='MyConnectionString']/@connectionString"> 
    <xsl:attribute name="connectionString">Data Source=MyServer;Initial Catalog=MyBD;User ID=user;password=pwd</xsl:attribute> 
</xsl:template> 
<xsl:template match="node()"> 
    <xsl:copy> 
     <xsl:apply-templates select="@*"/> 
     <xsl:apply-templates/> 
    </xsl:copy> 
</xsl:template> 

Answer 5

zawsze można użyć NANT + NAnt.Contrib zmodyfikować web.config podczas kompilacji. NAnt ma zadania xmlpeek i xmlpoke, które pozwalają na aktualizację plików xml.

np.

< xmlpoke file = "$ {dist.dir} /Web.config" xpath = "/ configuration/applicationSettings/MyProj.Web.Properties.Ustawienia/ustawienie [@name = 'MyProj_Web_Service']/value " value =" http: // {AppServer} /Service.asmx "/ >