ASP.NET Webbereitstellung mit Visual Studio: Web.config Dateitransformationen

von Tom Dykstra

Starter-Projekt herunterladen

In dieser Tutorialreihe erfahren Sie, wie Sie mithilfe von Visual Studio 2012 oder Visual Studio 2010 eine ASP.NET Webanwendung für Azure App Service Web-Apps oder für einen Hostinganbieter eines Drittanbieters bereitstellen (veröffentlichen). Informationen zur Reihe finden Sie im ersten Tutorial der Reihe.

Überblick

In diesem Tutorial erfahren Sie, wie Sie den Prozess zum Ändern der Web.config Datei automatisieren, wenn Sie sie in verschiedenen Zielumgebungen bereitstellen. Die meisten Anwendungen verfügen über Einstellungen in der Web.config-Datei , die sich bei der Bereitstellung der Anwendung unterscheiden müssen. Durch die Automatisierung des Prozesses der Änderungen müssen Sie diese bei jeder Bereitstellung nicht manuell durchführen, was mühsam und fehleranfällig wäre.

Erinnerung: Wenn Sie eine Fehlermeldung erhalten oder etwas nicht funktioniert, während Sie das Tutorial durchlaufen, überprüfen Sie unbedingt die Problembehandlungsseite.

Web.config von Transformationen im Vergleich zu WebBereitstellungsparametern

Es gibt zwei Möglichkeiten, den Prozess zum Ändern Web.config Dateieinstellungen zu automatisieren:Web.config Transformationen und Webbereitstellungsparameter. Eine Web.config Transformationsdatei enthält XML-Markup, das angibt, wie die Web.config Datei bei der Bereitstellung geändert werden soll. Sie können verschiedene Änderungen für bestimmte Buildkonfigurationen und für bestimmte Veröffentlichungsprofile angeben. Die Standardbuildkonfigurationen sind Debuggen und Release, und Sie können benutzerdefinierte Buildkonfigurationen erstellen. Ein Veröffentlichungsprofil entspricht in der Regel einer Zielumgebung. (Weitere Informationen zum Veröffentlichen von Profilen finden Sie im Tutorial Bereitstellen in IIS als Testumgebung .)

Web Deploy-Parameter können verwendet werden, um viele verschiedene Arten von Einstellungen anzugeben, die während der Bereitstellung konfiguriert werden müssen, einschließlich Einstellungen, die sich in Web.config Dateien befinden. Wenn sie verwendet werden, um Web.config Dateiänderungen anzugeben, sind Web Deploy-Parameter komplexer einzurichten, aber sie sind nützlich, wenn Sie den Wert nicht kennen, der bis zur Bereitstellung festgelegt werden soll. In einer Unternehmensumgebung können Sie beispielsweise ein Bereitstellungspaket erstellen und es einer Person in der IT-Abteilung zur Installation in der Produktion zuweisen, und diese Person muss in der Lage sein, Verbindungszeichenfolgen oder Kennwörter einzugeben, die Sie nicht kennen.

Für das Szenario, das in dieser Tutorialreihe behandelt wird, wissen Sie im Voraus, was für die Web.config-Datei getan werden muss, sodass Sie keine Webbereitstellungsparameter verwenden müssen. Sie konfigurieren einige Transformationen, die sich je nach verwendeter Buildkonfiguration unterscheiden, und einige, die sich je nach verwendetem Veröffentlichungsprofil unterscheiden.

Angeben Web.config Einstellungen in Azure

Wenn sich die Web.config Dateieinstellungen, die Sie ändern möchten, im <connectionStrings> -Element oder <appSettings> befinden, und wenn Sie die Bereitstellung in Web-Apps in Azure App Service durchführen, haben Sie eine weitere Option zum Automatisieren von Änderungen während der Bereitstellung. Sie können die Einstellungen eingeben, die In Azure wirksam werden sollen, auf der Registerkarte Konfigurieren der Verwaltungsportalseite für Ihre Web-App (scrollen Sie nach unten zu den Abschnitten App-Einstellungen und Verbindungszeichenfolgen ). Wenn Sie das Projekt bereitstellen, wendet Azure die Änderungen automatisch an. Weitere Informationen finden Sie unter Windows Azure-Websites: Funktionsweise von Anwendungszeichenfolgen und Verbindungszeichenfolgen.

Standardtransformationsdateien

Erweitern Sie Projektmappen-ExplorerWeb.config, um die Web.Debug.config- und Web.Release.config Transformationsdateien anzuzeigen, die standardmäßig für die beiden Standardbuildkonfigurationen erstellt werden.

Sie können Transformationsdateien für benutzerdefinierte Buildkonfigurationen erstellen, indem Sie mit der rechten Maustaste auf die Web.config Datei klicken und im Kontextmenü Konfigurationstransformationen hinzufügen auswählen. Für dieses Tutorial müssen Sie dies nicht tun, und die Menüoption ist deaktiviert, da Sie keine benutzerdefinierten Buildkonfigurationen erstellt haben.

Später erstellen Sie drei weitere Transformationsdateien, jeweils eine für die Test-, Staging- und Produktionsveröffentlichungsprofile. Ein typisches Beispiel für eine Einstellung, die Sie in einer Transformationsdatei für ein Veröffentlichungsprofil behandeln würden, da sie von der Zielumgebung abhängt, ist ein WCF-Endpunkt, der sich für Test und Produktion unterscheidet. Sie erstellen Veröffentlichungsprofiltransformationsdateien in späteren Tutorials, nachdem Sie die entsprechenden Veröffentlichungsprofile erstellt haben.

Deaktivieren des Debugmodus

Ein Beispiel für eine Einstellung, die von der Buildkonfiguration und nicht von der Zielumgebung abhängt, ist das debug -Attribut. Für einen Releasebuild sollten Sie das Debuggen in der Regel deaktivieren, unabhängig davon, in welcher Umgebung Sie die Bereitstellung durchführen. Daher erstellen die Visual Studio-Projektvorlagen standardmäßig Web.Release.config Transformdateien mit Code, der das debug Attribut aus dem compilation Element entfernt. Dies ist die Standard -Web.Release.config: Zusätzlich zu einem auskommentierten Beispieltransformationscode enthält er Code in das compilation Element, das das debug Attribut entfernt:

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

<!-- For more information on using web.config transformation visit https://go.microsoft.com/fwlink/?LinkId=125889 -->

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!--
    In the example below, the "SetAttributes" transform will change the value of 
    "connectionString" to use "ReleaseSQLServer" only when the "Match" locator 
    finds an attribute "name" that has a value of "MyDB".
    
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>
  -->
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <!--
      In the example below, the "Replace" transform will replace the entire 
      <customErrors> section of your web.config file.
      Note that because there is only one customErrors section under the 
      <system.web> node, there is no need to use the "xdt:Locator" attribute.
      
      <customErrors defaultRedirect="GenericError.htm"
        mode="RemoteOnly" xdt:Transform="Replace">
        <error statusCode="500" redirect="InternalError.htm"/>
      </customErrors>
    -->
  </system.web>
</configuration>

Das xdt:Transform="RemoveAttributes(debug)" Attribut gibt an, dass das debug Attribut aus dem Element in der system.web/compilation bereitgestellten Web.config-Datei entfernt werden soll. Dies erfolgt jedes Mal, wenn Sie einen Releasebuild bereitstellen.

Einschränken des Fehlerprotokollzugriffs auf Administratoren

Wenn während der Ausführung der Anwendung ein Fehler auftritt, zeigt die Anwendung anstelle der vom System generierten Fehlerseite eine generische Fehlerseite an, und sie verwendet das Elmah NuGet-Paket für die Fehlerprotokollierung und -berichterstellung. Das customErrors Element in der AnwendungsdateiWeb.config gibt die Fehlerseite an:

<customErrors mode="RemoteOnly" defaultRedirect="~/GenericErrorPage.aspx">
  <error statusCode="404" redirect="~/GenericErrorPage.aspx" />
</customErrors>

Um die Fehlerseite anzuzeigen, ändern Sie vorübergehend das mode Attribut des customErrors Elements von "RemoteOnly" in "Ein", und führen Sie die Anwendung in Visual Studio aus. Verursachen Sie einen Fehler, indem Sie eine ungültige URL anfordern, z . B. Studentsxxx.aspx. Anstelle einer von IIS generierten Fehlerseite "Die Ressource kann nicht gefunden werden" wird die Seite GenericErrorPage.aspx angezeigt.

Um das Fehlerprotokoll anzuzeigen, ersetzen Sie alles in der URL nach der Portnummer durch elmah.axd (z. B. http://localhost:51130/elmah.axd), und drücken Sie die EINGABETASTE:

Vergessen Sie nicht, das Element wieder in den customErrors Modus "RemoteOnly" zu versetzen, wenn Sie fertig sind.

Auf Ihrem Entwicklungscomputer ist es praktisch, freien Zugriff auf die Fehlerprotokollseite zuzulassen, aber in der Produktion wäre dies ein Sicherheitsrisiko. Für die Produktionswebsite möchten Sie eine Autorisierungsregel hinzufügen, die den Fehlerprotokollzugriff auf Administratoren einschränkt, und sicherstellen, dass die Einschränkung auch in Test und Staging funktioniert. Daher ist dies eine weitere Änderung, die Sie jedes Mal implementieren möchten, wenn Sie einen Releasebuild bereitstellen, und gehört daher in die Web.Release.config-Datei .

Öffnen Sie Web.Release.config , und fügen Sie ein neues location Element unmittelbar vor dem schließenden configuration Tag hinzu, wie hier gezeigt.

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <!--
    In the example below, the "SetAttributes" transform will change the value of 
    "connectionString" to use "ReleaseSQLServer" only when the "Match" locator 
    finds an attribute "name" that has a value of "MyDB".
    
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    </connectionStrings>
  -->
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <!--
      In the example below, the "Replace" transform will replace the entire 
      <customErrors> section of your web.config file.
      Note that because there is only one customErrors section under the 
      <system.web> node, there is no need to use the "xdt:Locator" attribute.
      
      <customErrors defaultRedirect="GenericError.htm"
        mode="RemoteOnly" xdt:Transform="Replace">
        <error statusCode="500" redirect="InternalError.htm"/>
      </customErrors>
    -->
  </system.web>
  <location path="elmah.axd" xdt:Transform="Insert">
    <system.web>
      <authorization>
        <allow roles="Administrator" />
        <deny users="*" />
      </authorization>
    </system.web>
  </location>
</configuration>

Der Transform Attributwert von "Insert" bewirkt, dass dieses location Element als gleichgeordnetes Element zu allen vorhandenen location Elementen in der Web.config-Datei hinzugefügt wird. (Es gibt bereits ein location Element, das Autorisierungsregeln für die Seite Guthaben aktualisieren angibt.)

Jetzt können Sie eine Vorschau der Transformation anzeigen, um sicherzustellen, dass Sie sie ordnungsgemäß codiert haben.

Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf Web.Release.config, und klicken Sie dann auf Vorschautransformation.

Es wird eine Seite geöffnet, auf der links die Entwicklungsdatei Web.config angezeigt wird und wie die bereitgestellte Web.config-Datei auf der rechten Seite mit hervorgehobenen Änderungen aussieht.

( In der Vorschau bemerken Sie möglicherweise einige zusätzliche Änderungen, für die Sie keine Transformationen geschrieben haben: Dies umfasst in der Regel das Entfernen von Leerraum, der sich nicht auf die Funktionalität auswirkt.)

Wenn Sie den Standort nach der Bereitstellung testen, testen Sie auch, ob die Autorisierungsregel wirksam ist.

Hinweis

Sicherheitshinweis Zeigen Sie keine Fehlerdetails für die Öffentlichkeit in einer Produktionsanwendung an, oder speichern Sie diese Informationen an einem öffentlichen Speicherort. Angreifer können Fehlerinformationen verwenden, um Sicherheitsrisiken auf einer Website zu entdecken. Wenn Sie ELMAH in Ihrer eigenen Anwendung verwenden, konfigurieren Sie ELMAH, um Sicherheitsrisiken zu minimieren. Das ELMAH-Beispiel in diesem Tutorial sollte nicht als empfohlene Konfiguration betrachtet werden. Es handelt sich um ein Beispiel, das ausgewählt wurde, um zu veranschaulichen, wie ein Ordner behandelt wird, in dem die Anwendung Dateien erstellen können muss. Weitere Informationen finden Sie unter Sichern des ELMAH-Endpunkts.

Eine Einstellung, die Sie in Veröffentlichungsprofiltransformationsdateien behandeln

Ein gängiges Szenario besteht darin, Web.config Dateieinstellungen zu haben, die sich in jeder Umgebung, in der Sie bereitstellen, unterscheiden müssen. Beispielsweise kann eine Anwendung, die einen WCF-Dienst aufruft, einen anderen Endpunkt in Test- und Produktionsumgebungen benötigen. Die Contoso University-Anwendung enthält auch eine solche Einstellung. Diese Einstellung steuert einen sichtbaren Indikator auf den Seiten einer Website, der Ihnen angibt, in welcher Umgebung Sie sich befinden, z. B. Entwicklung, Test oder Produktion. Der Einstellungswert bestimmt, ob die Anwendung "(Dev)" oder "(Test)" an die Standard Überschrift auf der Seite Site.Master master anfügen wird:

Der Umgebungsindikator wird weggelassen, wenn die Anwendung im Staging oder in der Produktion ausgeführt wird.

Auf den Webseiten der Contoso University wird ein Wert gelesen, der in appSettings der Web.config-Datei festgelegt ist, um zu bestimmen, in welcher Umgebung die Anwendung ausgeführt wird:

<appSettings>
    <add key="Environment" value="Dev" />
</appSettings>

Der Wert sollte in der Testumgebung "Test" und "Prod" für Staging und Produktion sein.

Der folgende Code in einer Transformationsdatei implementiert diese Transformation:

<appSettings>
    <add key="Environment" value="Test" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>

Der xdt:Transform Attributwert "SetAttributes" gibt an, dass der Zweck dieser Transformation darin besteht, Attributwerte eines vorhandenen Elements in der Web.config-Datei zu ändern. Der xdt:Locator Attributwert "Match(key)" gibt an, dass das zu ändernde Element das Element ist, dessen key Attribut dem key hier angegebenen Attribut entspricht. Das einzige andere Attribut des add Elements ist value, und das wird in der bereitgestellten Web.config-Datei geändert. Der hier gezeigte Code bewirkt, dass das value Attribut des EnvironmentappSettings Elements in der bereitgestelltenWeb.config Datei auf "Test" festgelegt wird.

Diese Transformation gehört in die Transformationsdateien für das Veröffentlichungsprofil, die Sie noch nicht erstellt haben. Sie erstellen und aktualisieren die Transformationsdateien, die diese Änderung implementieren, wenn Sie die Veröffentlichungsprofile für die Test-, Staging- und Produktionsumgebungen erstellen. Dies wird in den Tutorials "Bereitstellen in IIS" und "Bereitstellung in der Produktion" ausgeführt.

Hinweis

Da sich diese Einstellung im <appSettings> -Element befindet, haben Sie eine weitere Alternative zum Angeben der Transformation, wenn Sie die Bereitstellung in Web-Apps in Azure App Service siehe Angeben Web.config Einstellungen in Azure weiter oben in diesem Thema.

Festlegen von Verbindungszeichenfolgen

Obwohl die Standardtransformationsdatei ein Beispiel enthält, das zeigt, wie eine Verbindungszeichenfolge aktualisiert wird, müssen Sie in den meisten Fällen keine Verbindungszeichenfolgentransformationen einrichten, da Sie Verbindungszeichenfolgen im Veröffentlichungsprofil angeben können. Dies wird in den Tutorials "Bereitstellen in IIS" und "Bereitstellung in der Produktion" ausgeführt.

Zusammenfassung

Sie haben nun so viel wie möglich mit Web.config Transformationen getan, bevor Sie die Veröffentlichungsprofile erstellen, und Sie haben eine Vorschau der Elemente in der bereitgestellten Web.config-Datei gesehen.

Im folgenden Tutorial kümmern Sie sich um Bereitstellungssetupaufgaben, die das Festlegen von Projekteigenschaften erfordern.

Weitere Informationen

Weitere Informationen zu Themen, die in diesem Tutorial behandelt werden, finden Sie unter Verwenden Web.config Transformationen zum Ändern von Einstellungen im Ziel Web.config-Datei oder app.config-Datei während der Bereitstellung in der Inhaltsübersicht der Webbereitstellung für Visual Studio und ASP.NET.

ZurückWeiter