ASP.NET Webbereitstellung mit Visual Studio: Web.config Dateitransformationen
Von Tom Dykstra
In dieser Lernprogrammreihe wird gezeigt, wie Sie mithilfe von Visual Studio 2012 oder Visual Studio 2010 eine ASP.NET Webanwendung für Azure-App Service Web-Apps oder einem Drittanbieter-Hostinganbieter bereitstellen (veröffentlichen). Informationen zur Reihe finden Sie im ersten Lernprogramm in der Reihe.
Übersicht
In diesem Lernprogramm erfahren Sie, wie Sie den Prozess der Änderung der Web.config-Datei automatisieren, wenn Sie sie in verschiedenen Zielumgebungen bereitstellen. Die meisten Anwendungen verfügen über Einstellungen in der Datei "Web.config ", die bei der Bereitstellung der Anwendung unterschiedlich sein müssen. Durch die Automatisierung des Prozesses, diese Änderungen vorzunehmen, müssen Sie diese bei jeder Bereitstellung manuell ausführen, was mühsam und fehleranfällig wäre.
Erinnerung: Wenn Beim Durchlaufen des Lernprogramms eine Fehlermeldung angezeigt wird oder etwas nicht funktioniert, überprüfen Sie unbedingt die Problembehandlungsseite.
Web.config-Transformationen im Vergleich zu Web Deploy-Parametern
Es gibt zwei Möglichkeiten zum Automatisieren des Änderns von Web.config-Dateieinstellungen : Web.config-Transformationen und Web Deploy-Parameter. Eine Web.config-Transformationsdatei enthält XML-Markup, das angibt, wie die Web.config-Datei geändert wird, wenn sie bereitgestellt wird. Sie können unterschiedliche Änderungen für bestimmte Buildkonfigurationen und für bestimmte Veröffentlichungsprofile angeben. Die Standardbuildkonfigurationen sind Debug 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 Bereitstellen in IIS als Lernprogramm zur 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 in Web.config-Dateien gefunden werden. Wenn sie zum Angeben von Änderungen der Datei "Web.config " verwendet werden, sind Web Deploy-Parameter komplexer zum Einrichten, aber sie sind nützlich, wenn Sie nicht wissen, dass der Wert festgelegt werden soll, bis Sie die Bereitstellung durchführen. In einer Unternehmensumgebung können Sie beispielsweise ein Bereitstellungspaket erstellen und einer Person in der IT-Abteilung zur Installation in der Produktion zuweisen, und diese Person muss in der Lage sein, Verbindungszeichenfolge oder Kennwörter einzugeben, die Sie nicht kennen.
Für das Szenario, das diese Lernprogrammreihe behandelt, wissen Sie im Voraus alles, was für die Datei "Web.config " erforderlich ist, damit Sie keine Web Deploy-Parameter verwenden müssen. Sie konfigurieren einige Transformationen, die je nach verwendeter Buildkonfiguration unterschiedlich sind, und einige, die je nach verwendetem Veröffentlichungsprofil unterschiedlich sind.
Angeben von Web.config-Einstellungen in Azure
Wenn sich die Web.config-Dateieinstellungen, die Sie ändern möchten, im <connectionStrings>
Element befinden <appSettings>
und wenn Sie in Azure-App Dienst für Web-Apps bereitstellen, haben Sie eine weitere Option zum Automatisieren von Änderungen während der Bereitstellung. Sie können die Einstellungen eingeben, die In Azure auf der Registerkarte "Konfigurieren" der Verwaltungsportalseite für Ihre Web-App wirksam werden soll (scrollen Sie nach unten zu den App-Einstellungen und Verbindungszeichenfolge s Abschnitten). 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 in Projektmappen-Explorer Web.config, um die Transformationsdateien "Web.Debug.config" und "Web.Release.config" 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 Datei "Web.config" klicken und im Kontextmenü "Konfigurationstransformationen hinzufügen" auswählen. Für dieses Lernprogramm 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 Veröffentlichungsprofiltransformationsdatei behandeln würden, da sie von der Zielumgebung abhängt, ist ein WCF-Endpunkt, der sich für Tests im Vergleich zur Produktion unterscheidet. Sie erstellen die Veröffentlichungsprofiltransformationsdateien in späteren Lernprogrammen, nachdem Sie die Veröffentlichungsprofile erstellt haben, die sie verwenden.
Debugmodus deaktivieren
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 soll das Debuggen in der Regel deaktiviert werden, unabhängig davon, in welcher Umgebung Sie bereitstellen. Daher erstellen die Visual Studio-Projektvorlagen standardmäßig Web.Release.config Transformationsdateien mit Code, mit dem das debug
Attribut aus dem compilation
Element entfernt wird. Dies ist die Standardeinstellung "Web.Release.config": Zusätzlich zu einem Beispieltransformationscode, der auskommentiert ist, enthält es 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 system.web/compilation
Element in der 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 verwendet das Elmah NuGet-Paket für die Fehlerprotokollierung und -berichterstellung. Das customErrors
Element in der Datei " Application Web.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 aus Visual Studio aus. Verursacht einen Fehler, indem eine ungültige URL angefordert wird, z . B. Studentsxxx.aspx. Anstelle einer von IIS generierten Fehlerseite "Die Ressource kann nicht gefunden werden" wird die GenericErrorPage.aspx Seite 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 customErrors
Element wieder auf den "RemoteOnly"-Modus festzulegen, wenn Sie fertig sind.
Auf Ihrem Entwicklungscomputer ist es praktisch, den kostenlosen Zugriff auf die Fehlerprotokollseite zu ermöglichen, 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 um sicherzustellen, 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 Release-Build bereitstellen, und daher gehört sie zur Datei "Web.Release.config" .
Ö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 Datei "Web.config " 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 richtig codiert haben.
Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf "Web.Release.config", und klicken Sie auf "Vorschautransformation".
Eine Seite wird geöffnet, auf der die Entwicklungsdatei "Web.config " auf der linken Seite angezeigt wird und wie die bereitgestellte Web.config-Datei auf der rechten Seite aussieht, wobei Die Änderungen hervorgehoben sind.
( In der Vorschau bemerken Sie möglicherweise einige zusätzliche Änderungen, für die Sie keine Transformationen geschrieben haben: Diese umfassen in der Regel das Entfernen von Leerzeichen, die sich nicht auf die Funktionalität auswirken.)
Wenn Sie die Website nach der Bereitstellung testen, testen Sie auch, ob die Autorisierungsregel wirksam ist.
Hinweis
Sicherheitshinweis zeigt niemals 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 ermitteln. Wenn Sie ELMAH in Ihrer eigenen Anwendung verwenden, konfigurieren Sie ELMAH, um Sicherheitsrisiken zu minimieren. Das ELMAH-Beispiel in diesem Lernprogramm sollte nicht als empfohlene Konfiguration betrachtet werden. Es ist ein Beispiel, das ausgewählt wurde, um zu veranschaulichen, wie ein Ordner behandelt wird, in dem die Anwendung Dateien erstellen kann. Weitere Informationen finden Sie unter Sichern des ELMAH-Endpunkts.
Eine Einstellung, die Sie in Veröffentlichungsprofiltransformationsdateien behandeln werden
Ein häufiges Szenario besteht darin, dass Die Dateieinstellungen von Web.config in den einzelnen Umgebungen, für die Sie bereitstellen, unterschiedlich sein müssen. Beispielsweise benötigt eine Anwendung, die einen WCF-Dienst aufruft, möglicherweise einen anderen Endpunkt in Test- und Produktionsumgebungen. Die Contoso University-Anwendung enthält auch eine Einstellung dieser Art. Diese Einstellung steuert einen sichtbaren Indikator auf den Seiten einer Website, die 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 Hauptüberschrift auf der Gestaltungsvorlage "Site.Master " anfügen soll:
Der Umgebungsindikator wird ausgelassen, wenn die Anwendung im Staging oder in der Produktion ausgeführt wird.
Die Webseiten der Contoso University lesen einen Wert, der in appSettings
der Datei "Web.config " 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 das Ändern von Attributwerten eines vorhandenen Elements in der Web.config-Datei ist. Der xdt:Locator
Attributwert "Match(key)" gibt an, dass das zu ändernde Element das Attribut ist, dessen key
Attribut dem key
hier angegebenen Attribut entspricht. Das einzige andere Attribut des add
Elements ist value
, und das ist, was in der bereitgestellten Web.config-Datei geändert wird. Der hier gezeigte Code bewirkt, dass das value
Attribut des Environment
appSettings
Elements in der bereitgestellten Web.config-Datei auf "Test" festgelegt wird.
Diese Transformation gehört zu den Veröffentlichungsprofiltransformationsdateien, 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 der Bereitstellung für IIS und für Produktionslernprogramme ausgeführt.
Hinweis
Da sich diese Einstellung im <appSettings>
Element befindet, haben Sie eine weitere Alternative zum Angeben der Transformation, wenn Sie in Web-Apps Azure-App Dienst bereitstellen, siehe Angeben von Web.config-Einstellungen in Azure weiter oben in diesem Thema.
Festlegen von Verbindungszeichenfolgen
Obwohl die Standardtransformationsdatei ein Beispiel enthält, das zeigt, wie ein Verbindungszeichenfolge aktualisiert wird, müssen Sie in den meisten Fällen keine Verbindungszeichenfolge Transformationen einrichten, da Sie Verbindungszeichenfolge im Veröffentlichungsprofil angeben können. Dies wird in der Bereitstellung für IIS und für Produktionslernprogramme ausgeführt.
Zusammenfassung
Sie haben jetzt so viel wie möglich mit Web.config-Transformationen ausgeführt, bevor Sie die Veröffentlichungsprofile erstellen, und Sie haben eine Vorschau der Elemente in der bereitgestellten Web.config-Datei gesehen.
Im folgenden Lernprogramm kümmern Sie sich um Bereitstellungssetupaufgaben, die das Festlegen von Projekteigenschaften erfordern.
Weitere Informationen
Weitere Informationen zu Themen, die in diesem Lernprogramm behandelt werden, finden Sie unter Verwenden von Web.config-Transformationen zum Ändern von Einstellungen in der Zieldatei "Web.config" oder "app.config" während der Bereitstellung in der Inhaltszuordnung für Webbereitstellung für Visual Studio und ASP.NET.