Bereitstellen einer ASP.NET Webanwendung mit SQL Server Compact mithilfe von Visual Studio oder Visual Web Developer: Web.Config Dateitransformationen – 3 von 12

von Tom Dykstra

Herunterladen des Starterprojekts

In dieser Reihe von Tutorials erfahren Sie, wie Sie mithilfe von Visual Studio 2012 RC oder Visual Studio Express 2012 RC für Web ein ASP.NET Webanwendungsprojekt bereitstellen (veröffentlichen), das eine SQL Server Compact-Datenbank enthält. Sie können visual Studio 2010 auch verwenden, wenn Sie das Web Publish Update installieren. Eine Einführung in die Reihe finden Sie im ersten Tutorial der Reihe.

Ein Tutorial, das bereitstellungsfeatures zeigt, die nach der RC-Version von Visual Studio 2012 eingeführt wurden, zeigt, wie SQL Server anderen Editionen als SQL Server Compact bereitgestellt werden, und zeigt, wie sie in Azure App Service Web-Apps bereitgestellt werden, finden Sie unter ASP.NET Webbereitstellung mit Visual Studio.

Ü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 unterscheiden müssen, wenn die Anwendung bereitgestellt wird. Durch die Automatisierung des Prozesses, diese Änderungen vorzunehmen, müssen Sie diese bei jeder Bereitstellung nicht manuell vornehmen, 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 Seite zur Problembehandlung.

Web.config Transformationen im Vergleich zu Web Deploy-Parametern

Es gibt zwei Möglichkeiten, den Prozess der Änderung Web.config Dateieinstellungen zu automatisieren:Web.config Transformationen und Web Deploy-Parameter. 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 Standardmäßigen Buildkonfigurationen sind Debug und Release, und Sie können benutzerdefinierte Buildkonfigurationen erstellen. Ein Veröffentlichungsprofil entspricht in der Regel einer Zielumgebung. (Weitere Informationen zu Veröffentlichungsprofilen 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 zum Angeben Web.config Dateiänderungen verwendet werden, sind Web Deploy-Parameter komplexer einzurichten, aber sie sind nützlich, wenn Sie den festzulegenden Wert erst kennen, wenn Sie die Bereitstellung durchführen. In einer Unternehmensumgebung können Sie beispielsweise ein Bereitstellungspaket erstellen und es einer Person in der IT-Abteilung zur Installation in der Produktion übergeben, und diese Person muss in der Lage sein, Verbindungszeichenfolgen oder Kennwörter einzugeben, die Sie nicht kennen.

Für das Szenario, das in diesem Tutorial behandelt wird, wissen Sie, was für die Web.config-Datei ausgeführt werden muss, sodass Sie keine Web Deploy-Parameter verwenden müssen. Sie konfigurieren einige Transformationen, die sich je nach verwendeter Buildkonfiguration unterscheiden, und einige, die sich je nach verwendetem Veröffentlichungsprofil unterscheiden.

Erstellen von Transformationsdateien für Veröffentlichungsprofile

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 jedoch nicht tun.

Sie benötigen zwei weitere Transformationsdateien, um Änderungen zu konfigurieren, die sich auf das Bereitstellungsziel und nicht auf die Buildkonfiguration beziehen. Ein typisches Beispiel für diese Art von Einstellung ist ein WCF-Endpunkt, der sich für Test und Produktion unterscheidet. In späteren Tutorials erstellen Sie Veröffentlichungsprofile mit den Namen Test und Produktion, sodass Sie eine Web.Test.config-Datei und eine Web.Production.config-Datei benötigen.

Transformationsdateien, die an Veröffentlichungsprofile gebunden sind, müssen manuell erstellt werden. Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf das Projekt ContosoUniversity, und wählen Sie Ordner in Windows Explorer öffnen aus.

Wählen Sie in Windows Explorer die Web.Release.config Datei aus, kopieren Sie die Datei, und fügen Sie dann zwei Kopien davon ein. Benennen Sie diese Kopien Web.Production.config und Web.Test.configum, und schließen Sie windows Explorer.

Klicken Sie Projektmappen-Explorer auf Aktualisieren, um die neuen Dateien anzuzeigen.

Wählen Sie die neuen Dateien aus, klicken Sie mit der rechten Maustaste, und klicken Sie dann im Kontextmenü auf In Projekt einschließen .

Um zu verhindern, dass diese Dateien bereitgestellt werden, wählen Sie sie in Projektmappen-Explorer aus, und ändern Sie dann im Fenster Eigenschaften die Eigenschaft Buildaktion von Inhalt in Keine. (Transformationsdateien, die auf Buildkonfigurationen basieren, werden automatisch an der Bereitstellung gehindert.)

Sie können nun Web.config Transformationen in dieWeb.config-Transformationsdateien eingeben.

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 Web.config-Datei 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 "Seite nicht gefunden" wird die Seite GenericErrorPage.aspx angezeigt.

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

Vergessen Sie nicht, das Element wieder auf den customErrors Modus "RemoteOnly" festzulegen, 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 können Sie eine Autorisierungsregel hinzufügen, die den Fehlerprotokollzugriff nur auf Administratoren beschränkt, indem Sie eine Transformation in der Web.Production.config-Datei konfigurieren.

Öffnen Sie Web.Production.config, und fügen Sie unmittelbar nach dem öffnenden configuration Tag ein neues location Element hinzu, wie hier gezeigt. (Stellen Sie sicher, dass Sie nur das location -Element und nicht das umgebende Markup hinzufügen, das hier nur angezeigt wird, um kontextabhängig zu sein.)

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <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.) Wenn Sie den Produktionsstandort nach der Bereitstellung testen, überprüfen Sie, ob diese Autorisierungsregel wirksam ist.

Sie müssen den Fehlerprotokollzugriff in der Testumgebung nicht einschränken, sodass Sie diesen Code nicht der Web.Test.config-Datei hinzufügen müssen.

Hinweis

Sicherheitshinweis Zeigen Sie 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 einem Standort zu ermitteln. Wenn Sie ELMAH in Ihrer eigenen Anwendung verwenden, sollten Sie prüfen, wie ELMAH konfiguriert werden kann, um Sicherheitsrisiken zu minimieren. Das ELMAH-Beispiel in diesem Tutorial sollte nicht als empfohlene Konfiguration angesehen 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 kann.

Festlegen eines Umgebungsindikators

Ein häufiges Szenario besteht darin, Web.config Dateieinstellungen zu verwenden, die in jeder Umgebung, in der 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, der Ihnen mitteilt, 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 in der Produktion ausgeführt wird.

Die Webseiten der Contoso University lesen einen Wert, 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 in der Produktionsumgebung "Prod" sein.

Öffnen Sie Web.Production.config, und fügen Sie unmittelbar vor dem öffnenden Tag des Elements, das location Sie zuvor hinzugefügt haben, ein appSettings Element hinzu:

<appSettings>
    <add key="Environment" value="Prod" 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 mit dem key hier angegebenen Attribut übereinstimmt. Das einzige andere Attribut des add Elements ist value, und das wird in der bereitgestellten Web.config-Datei geändert. Dieser Code bewirkt, dass das value Attribut des EnvironmentappSettings Elements in der Web.config-Datei , die in der Produktion bereitgestellt wird, auf "Prod" festgelegt wird.

Wenden Sie als Nächstes die gleiche Änderung auf Web.Test.config Datei an, mit der Ausnahme, dass value auf "Test" anstelle von "Prod" festgelegt wird. Wenn Sie fertig sind, sieht der appSettings Abschnitt in Web.Test.config wie im folgenden Beispiel aus:

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

Deaktivieren des Debugmodus

Für einen Releasebuild möchten Sie das Debuggen unabhängig davon, in welcher Umgebung Sie bereitstellen, nicht aktiviert sein. Standardmäßig wird die Web.Release.config Transformationsdatei automatisch mit Code erstellt, der das debug Attribut aus dem compilation -Element entfernt:

<system.web>
  <compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>

Das Transform -Attribut bewirkt, dass das debug Attribut in der bereitgestellten Web.config-Datei weggelassen wird, wenn Sie einen Releasebuild bereitstellen.

Dieselbe Transformation befindet sich in Den Transformationsdateien für Test und Produktion, da Sie sie durch Kopieren der Releasetransformationsdatei erstellt haben. Sie müssen es dort nicht dupliziert haben. Öffnen Sie also jede dieser Dateien, entfernen Sie das Kompilierungselement , und speichern und schließen Sie jede Datei.

Festlegen von Verbindungszeichenfolgen

In den meisten Fällen müssen Sie keine Verbindungszeichenfolgentransformationen einrichten, da Sie Verbindungszeichenfolgen im Veröffentlichungsprofil angeben können. Es gibt jedoch eine Ausnahme, wenn Sie eine SQL Server Compact-Datenbank bereitstellen und Entity Framework Code First-Migrationen verwenden, um die Datenbank auf dem Zielserver zu aktualisieren. In diesem Szenario müssen Sie eine zusätzliche Verbindungszeichenfolge angeben, die auf dem Server zum Aktualisieren des Datenbankschemas verwendet wird. Um diese Transformation einzurichten, fügen Sie unmittelbar nach dem öffnenden <Konfigurationstag> in den Web.Test.config- und Web.Production.configTransformationsdateien ein< connectionStrings-Element> hinzu:

<connectionStrings>
  <add name="SchoolContext_DatabasePublish" connectionString="Data Source=|DataDirectory|School-Prod.sdf" providerName="System.Data.SqlServerCe.4.0" xdt:Transform="Insert"/>
</connectionStrings>

Das Transform -Attribut gibt an, dass diese Verbindungszeichenfolge dem connectionStrings-Element in der bereitgestellten Web.config-Datei hinzugefügt wird. (Der Veröffentlichungsprozess erstellt diese zusätzliche Verbindungszeichenfolge automatisch für Sie, wenn sie nicht vorhanden ist, aber standardmäßig wird das attribut providerName auf System.Data.SqlClientfestgelegt, was für SQL Server Compact nicht funktioniert. Durch manuelles Hinzufügen der Verbindungszeichenfolge wird verhindert, dass der Bereitstellungsprozess ein Verbindungszeichenfolgenelement mit dem falschen Anbieternamen erstellt.)

Sie haben nun alle Web.config Transformationen angegeben, die Sie für die Bereitstellung der Contoso University-Anwendung zum Testen und zur Produktion benötigen. Im folgenden Tutorial kümmern Sie sich um Bereitstellungssetuptasks, die das Festlegen von Projekteigenschaften erfordern.

Weitere Informationen

Weitere Informationen zu Themen, die in diesem Tutorial behandelt werden, finden Sie unter Web.config Transformationsszenario in ASP.NET Bereitstellungsinhaltszuordnung.

ZurückWeiter