Allgemeine Konfigurationsunterschiede zwischen Entwicklung und Produktion (VB)

von Scott Mitchell

PDF herunterladen

In früheren Lernprogrammen haben wir unsere Website bereitgestellt, indem wir alle relevanten Dateien aus der Entwicklungsumgebung in die Produktionsumgebung kopieren. Es ist jedoch nicht ungewöhnlich, dass zwischen Umgebungen Konfigurationsunterschiede bestehen, was erfordert, dass jede Umgebung über eine eindeutige Web.config Datei verfügt. In diesem Lernprogramm werden typische Konfigurationsunterschiede untersucht und Strategien zum Verwalten separater Konfigurationsinformationen untersucht.

Einführung

Die letzten beiden Tutorials führten durch die Bereitstellung einer einfachen Webanwendung. Das Lernprogramm "Deploying Your Site Using an FTP Client " hat gezeigt, wie Sie einen eigenständigen FTP-Client verwenden, um die erforderlichen Dateien aus der Entwicklungsumgebung bis zur Produktion zu kopieren. Im vorherigen Lernprogramm, Bereitstellen Ihrer Website mit Visual Studio, wurde die Bereitstellung mit dem Tool zum Kopieren der Website und der Veröffentlichungsoption von Visual Studio untersucht. In beiden Lernprogrammen war jede Datei in der Produktionsumgebung eine Kopie einer Datei in der Entwicklungsumgebung. Es ist jedoch nicht ungewöhnlich, dass Konfigurationsdateien in der Produktionsumgebung von denen in der Entwicklungsumgebung abweichen. Die Konfiguration einer Webanwendung wird in der Datei gespeichert und enthält in der Web.config Regel Informationen zu externen Ressourcen, z. B. Datenbank-, Web- und E-Mail-Server. Außerdem wird das Verhalten der Anwendung in bestimmten Situationen beschrieben, z. B. der Vorgang, der ausgeführt werden soll, wenn eine unbehandelte Ausnahme auftritt.

Bei der Bereitstellung einer Webanwendung ist es wichtig, dass die richtigen Konfigurationsinformationen in der Produktionsumgebung enden. In den meisten Fällen kann die Datei Web.config in der Entwicklungsumgebung nicht unverändert in die Produktionsumgebung kopiert werden. Stattdessen muss eine angepasste Version der Web.config Datei in die Produktion hochgeladen werden. In diesem Lernprogramm werden einige der häufigeren Konfigurationsunterschiede kurz überprüft. Außerdem werden einige Techniken für die Aufrechterhaltung unterschiedlicher Konfigurationsinformationen zwischen den Umgebungen zusammengefasst.

Typische Konfigurationsunterschiede zwischen Entwicklungs- und Produktionsumgebungen

Die Web.config Datei enthält eine Reihe von Konfigurationsinformationen für eine ASP.NET Anwendung. Einige dieser Konfigurationsinformationen sind unabhängig von der Umgebung identisch. Beispielsweise sind die Authentifizierungseinstellungen und URL-Autorisierungsregeln, die in den Web.config- und <authentication>-Elementen der <authorization>-Datei festgelegt sind, normalerweise gleich, unabhängig von der Umgebung. Andere Konfigurationsinformationen , z. B. Informationen zu externen Ressourcen, unterscheiden sich in der Regel je nach Umgebung.

Datenbankverbindungszeichenfolgen sind ein erstklassiges Beispiel für Konfigurationsinformationen, die sich je nach Umgebung unterscheiden. Wenn eine Webanwendung mit einem Datenbankserver kommuniziert, muss sie zunächst eine Verbindung herstellen und dies über eine Verbindungszeichenfolge erreicht wird. Obwohl es möglich ist, die Datenbank-Verbindungszeichenfolge direkt in den Webseiten oder im Code, der eine Verbindung zur Datenbank herstellt, fest einzuarbeiten (hard-coden), ist es am besten, sie im Web.config<connectionStrings>-Element zu platzieren, sodass die Informationen zur Verbindungszeichenfolge an einem einzigen zentralen Ort gespeichert sind. Häufig wird eine andere Datenbank während der Entwicklung verwendet, als in der Produktion verwendet wird; Daher müssen die Verbindungszeichenfolgeninformationen für jede Umgebung eindeutig sein.

Das beabsichtigte Verhalten der Entwicklungs- und Produktionsumgebungen unterscheidet sich erheblich. Eine Webanwendung in der Entwicklungsumgebung wird von einer kleinen Gruppe von Entwicklern erstellt, getestet und gedebuggt. In der Produktionsumgebung wird dieselbe Anwendung von vielen verschiedenen gleichzeitigen Benutzern besucht. ASP.NET enthält eine Reihe von Features, die Entwicklern beim Testen und Debuggen einer Anwendung helfen, aber diese Features sollten aus Leistungs- und Sicherheitsgründen in der Produktionsumgebung deaktiviert werden. Sehen wir uns einige solche Konfigurationseinstellungen an.

Konfigurationseinstellungen, die sich auf die Leistung auswirken

Wenn eine ASP.NET Seite zum ersten Mal besucht wird (oder wenn sie zum ersten Mal geändert wurde), muss das deklarative Markup in eine Klasse konvertiert werden, und diese Klasse muss kompiliert werden. Wenn die Webanwendung die automatische Kompilierung verwendet, muss auch die CodeBehind-Klasse der Seite kompiliert werden. Sie können eine Reihe von Kompilierungsoptionen über das Element der Web.config Datei <compilation>konfigurieren.

Das Debug-Attribut ist eines der wichtigsten Attribute im <compilation> Element. Wenn das debug Attribut auf "true" festgelegt ist, enthalten die kompilierten Assemblys Debugsymbole, die beim Debuggen einer Anwendung in Visual Studio benötigt werden. Debugsymbole erhöhen jedoch die Größe der Assembly und stellen beim Ausführen des Codes zusätzliche Speicheranforderungen auf. Wenn das debug Attribut auf "true" festgelegt ist, werden alle Inhalte, die von WebResource.axd zurückgegeben werden, nicht zwischengespeichert. Das bedeutet, dass jedes Mal, wenn ein Benutzer eine Seite besucht, der statische Inhalt von WebResource.axd erneut heruntergeladen werden muss.

Das <compilation> Attribut des debug Elements wird in der Regel in der Entwicklungsumgebung auf "true" festgelegt. Tatsächlich muss dieses Attribut auf "true" festgelegt werden, um eine Webanwendung zu debuggen; Wenn Sie versuchen, eine ASP.NET Anwendung aus Visual Studio zu debuggen und das debug Attribut auf "false" festgelegt ist, zeigt Visual Studio eine Meldung an, in der erläutert wird, dass die Anwendung erst debuggt werden kann, wenn das debug Attribut auf "true" festgelegt ist, und bietet an, diese Änderung für Sie vorzunehmen.

Sie sollten das Attribut debug auf "true" in einer Produktionsumgebung festlegen lassen, da sich dies auf die Leistung auswirkt. Eine ausführlichere Diskussion zu diesem Thema finden Sie im Blogbeitrag von Scott Guthrie, "ASP.NET-Anwendungen in der Produktion nicht mit debug="true" aktiviert ausführen."

Benutzerdefinierte Fehler und Nachverfolgung

Wenn eine unbehandelte Ausnahme in einer ASP.NET-Anwendung auftritt, wird sie bis zum Runtime weitergereicht, wo einer von drei Fällen eintritt:

• Es wird eine generische Laufzeitfehlermeldung angezeigt. Diese Seite informiert den Benutzer darüber, dass ein Laufzeitfehler aufgetreten ist, aber keine Details zum Fehler enthält.
• Es wird eine Meldung mit Ausnahmedetails angezeigt, die Informationen zu der soeben ausgelösten Ausnahme enthält.
• Es wird eine benutzerdefinierte Fehlerseite angezeigt, bei der es sich um eine von Ihnen erstellte ASP.NET Seite handelt, die jede gewünschte Meldung anzeigt.

Im Falle einer unbehandelten Ausnahme hängt ab, was geschieht, von dem Abschnitt der Web.config Datei <customErrors>.

Beim Entwickeln und Testen einer Anwendung hilft es, Details zu jeder Ausnahme im Browser anzuzeigen. Das Anzeigen von Ausnahmedetails in einer Anwendung in der Produktion ist jedoch ein potenzielles Sicherheitsrisiko. Darüber hinaus ist es unblästigend und macht Ihre Website unprofessionell aus. Im Idealfall zeigt eine Webanwendung in der Entwicklungsumgebung die Details der Ausnahme an, während dieselbe Anwendung in der Produktion eine benutzerdefinierte Fehlerseite anzeigt.

Ein weiteres ASP.NET Feature, das während der Entwicklung nützlich ist, ist die Ablaufverfolgung. Wenn aktiviert, zeichnet die Nachverfolgung Informationen über jede eingehende Anforderung auf und stellt eine spezielle Webseite, Trace.axd, zur Verfügung, um aktuelle Anforderungsdetails anzuzeigen. Sie können die Ablaufverfolgung aktivieren und konfigurieren, indem Sie das <trace> Element in Web.config verwenden.

Wenn Sie die Ablaufverfolgung aktivieren, stellen Sie sicher, dass sie in der Produktionsumgebung deaktiviert ist. Da die Ablaufverfolgungsinformationen Cookies, Sitzungsdaten und andere potenziell vertrauliche Informationen enthalten, ist es wichtig, die Ablaufverfolgung in der Produktion zu deaktivieren. Die gute Nachricht ist, dass die Ablaufverfolgung standardmäßig deaktiviert ist und auf die Trace.axd Datei nur über localhost zugegriffen werden kann. Wenn Sie diese Standardeinstellungen in der Entwicklung ändern, stellen Sie sicher, dass sie in der Produktion wieder deaktiviert sind.

Techniken für die Verwaltung separater Konfigurationsinformationen

Wenn Sie unterschiedliche Konfigurationseinstellungen in den Entwicklungs- und Produktionsumgebungen verwenden, wird der Bereitstellungsprozess erschwert. In den vorherigen beiden Lernprogrammen hat der Bereitstellungsprozess das Kopieren aller erforderlichen Dateien von der Entwicklung in die Produktion durchgeführt, aber dieser Ansatz funktioniert nur, wenn die Konfigurationsinformationen in beiden Umgebungen identisch sind. Es gibt eine Vielzahl von Techniken für die Bereitstellung einer Anwendung mit unterschiedlichen Konfigurationsinformationen. Lassen Sie uns einige dieser Optionen für gehostete Webanwendungen katalogisieren.

Manuelle Bereitstellung der Konfigurationsdatei für die Produktionsumgebung

Der einfachste Ansatz besteht darin, zwei Versionen der Web.config Datei beizubehalten: eine für die Entwicklungsumgebung und eine für die Produktionsumgebung. Die Bereitstellung einer Website für die Produktion erfordert das Kopieren aller Dateien auf den Produktionsserver in der Entwicklungsumgebung mit Ausnahme der Web.config Datei. Stattdessen würde die produktionsumgebungsspezifische Web.config Datei in die Produktion kopiert.

Dieser Ansatz ist nicht sehr anspruchsvoll, aber es ist einfach zu implementieren, da sich Konfigurationsinformationen selten ändern. Es eignet sich am besten für Anwendungen mit einem kleinen Entwicklungsteam, das auf einem einzelnen Webserver gehostet wird und dessen Konfigurationsinformationen selten geändert werden. Es ist am praktikabelsten, wenn die Anwendungsdateien manuell mit einem eigenständigen FTP-Client bereitgestellt werden. Wenn Sie das Tool "Website kopieren" oder die Option "Veröffentlichen" von Visual Studio verwenden, müssen Sie zuerst die bereitstellungsspezifische Datei mit der produktionsspezifischen Web.config Datei austauschen, bevor Sie sie bereitstellen, und dann nach Abschluss der Bereitstellung wieder austauschen.

Ändern der Konfiguration während des Build- oder Bereitstellungsprozesses

Die bisher geführten Diskussionen haben einen ad-hoc-Build- und Bereitstellungsprozess vorausgesetzt. Viele größere Softwareprojekte verfügen über formalisierte Prozesse, die Open-Source-, Heim- oder Drittanbietertools nutzen. Für solche Projekte können Sie den Build- oder Bereitstellungsprozess wahrscheinlich anpassen, um die Konfigurationsinformationen entsprechend zu ändern, bevor sie an die Produktion übertragen wird. Wenn Sie Ihre Webanwendung mit MSBuild, NAnt oder einem anderen Buildtool erstellen, können Sie wahrscheinlich einen Buildschritt hinzufügen, um die Web.config Datei so zu ändern, dass sie die produktionsspezifischen Einstellungen enthält. Oder Ihr Bereitstellungsworkflow kann programmgesteuert eine Verbindung mit dem Quellcodeverwaltungsserver herstellen und die entsprechende Web.config Datei abrufen.

Der tatsächliche Ansatz zum Abrufen der geeigneten Konfigurationsinformationen zur Produktion variiert je nach Ihren Tools und Workflows stark. Daher werden wir uns nicht weiter in dieses Thema eintauchen. Wenn Sie ein beliebtes Buildtool wie MSBuild oder NAnt verwenden, finden Sie Bereitstellungsartikel und Lernprogramme speziell für diese Tools über eine Websuche.

Verwaltung von Konfigurationsunterschieden über das Webbereitstellungsprojekt-Add-In

2006 veröffentlichte Microsoft das Webentwicklungsprojekt Add-In für Visual Studio 2005. Ein Add-In für Visual Studio 2008 wurde 2008 veröffentlicht. Mit diesem Add-In können ASP.NET-Entwickler ein separates Web Deployment-Projekt zusammen mit ihrem Webanwendungsprojekt erstellen, bei dem die Webanwendung explizit kompiliert wird und die Dateien, die bereitgestellt werden sollen, in ein lokales Ausgabeverzeichnis kopiert werden. Das Webanwendungsprojekt verwendet MSBuild hinter den Kulissen.

Standardmäßig wird die Datei der Entwicklungsumgebung Web.config in das Ausgabeverzeichnis kopiert. Sie können jedoch das Webbereitstellungsprojekt so einrichten, dass Sie die Anpassungen vornehmen können.

Konfigurationsinformationen, die auf folgende Weise in dieses Verzeichnis kopiert werden:

• Über Web.config den Austausch von Dateiabschnitten, in dem Sie den zu ersetzenden Abschnitt und eine XML-Datei angeben, die den Ersetzungstext enthält.
• Durch Bereitstellen eines Pfads zu einer externen Konfigurationsquelldatei. Wenn diese Option ausgewählt ist, kopiert das Webbereitstellungsprojekt eine bestimmte Web.config Datei in das Ausgabeverzeichnis (anstelle der Web.config datei, die in der Entwicklungsumgebung verwendet wird).
• Durch Hinzufügen von benutzerdefinierten Regeln zur MSBuild-Datei, die vom Webbereitstellungsprojekt verwendet wird.

Um die Webanwendung bereitzustellen, erstellen Sie das Webbereitstellungsprojekt, und kopieren Sie dann die Dateien aus dem Ausgabeordner des Projekts in die Produktionsumgebung.

Weitere Informationen zur Verwendung des Webbereitstellungsprojekts finden Sie in diesem Artikel zu Webbereitstellungsprojekten aus der Ausgabe vom April 2007 des MSDN Magazines, oder lesen Sie die Links im Abschnitt "Weiteres Lesen" am Ende dieses Lernprogramms.

Zusammenfassung

Die externen Ressourcen und das Verhalten einer Webanwendung in der Entwicklung unterscheiden sich in der Regel davon, wenn sich dieselbe Anwendung in der Produktion befindet. Beispielsweise unterscheiden sich Datenbankverbindungszeichenfolgen, Kompilierungsoptionen und das Verhalten, wenn eine unbehandelte Ausnahme auftritt, häufig zwischen Umgebungen. Der Bereitstellungsprozess muss diese Unterschiede berücksichtigen. Wie in diesem Lernprogramm erläutert, besteht der einfachste Ansatz darin, eine alternative Konfigurationsdatei manuell in die Produktionsumgebung zu kopieren. Elegantere Lösungen sind möglich, wenn Sie das Web deployment Project Add-In oder mit einem formaleren Build- oder Bereitstellungsprozess verwenden, der solche Anpassungen berücksichtigen kann.

Glückliche Programmierung!

Weiterführende Lektüre

Weitere Informationen zu den in diesem Lernprogramm erläuterten Themen finden Sie in den folgenden Ressourcen:

• Erläuterte Verbindungszeichenfolgen
• Datenbankverbindungszeichenfolgen @ ConnectionStrings.com
• Führen Sie keine Produktions-ASP.NET-Anwendungen mit debug="true" aktivierter Option aus
• Ordnungsgemäßes Reagieren auf unbehandelte Ausnahmen und Anzeigen benutzerfreundlicher Fehlerseiten
• Schlüsselkonfigurationseinstellungen beim Bereitstellen einer Datenbank
• VS 2008 Web Deployment Projects | Vs 2008 Web Deployment Project Support veröffentlicht
• Webbereitstellungsprojekte