Share via

Allgemeine Konfigurationsunterschiede zwischen Entwicklungs- und Produktionsumgebungen (VB)

  • Artikel

von Scott Mitchell

PDF herunterladen

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

Einführung

In den letzten beiden Tutorials wurde die Bereitstellung einer einfachen Webanwendung erläutert. Im Tutorial Deploying Your Site Using an FTP Client (Bereitstellen ihrer Website mithilfe eines FTP-Clients ) wurde gezeigt, wie Sie einen eigenständigen FTP-Client verwenden, um die erforderlichen Dateien aus der Entwicklungsumgebung in die Produktion zu kopieren. Im vorherigen Tutorial Deploying Your Site Using Visual Studio (Bereitstellen Ihrer Website mithilfe von Visual Studio) wurde die Bereitstellung mit dem Tool "Website kopieren" von Visual Studio und der Option "Veröffentlichen" behandelt. In beiden Tutorials war jede Datei in der Produktionsumgebung eine Kopie einer Datei in der Entwicklungsumgebung. Es ist jedoch nicht ungewöhnlich, dass sich Konfigurationsdateien in der Produktionsumgebung von denen in der Entwicklungsumgebung unterscheiden. Die Konfiguration einer Webanwendung wird in der Datei gespeichert und enthält in der Web.config Regel Informationen zu externen Ressourcen wie Datenbank-, Web- und E-Mail-Servern. Außerdem wird das Verhalten der Anwendung in bestimmten Situationen beschrieben, z. B. die Vorgehensweise, die ausgeführt werden soll, wenn eine nicht behandelte Ausnahme auftritt.

Beim Bereitstellen einer Webanwendung ist es wichtig, dass die richtigen Konfigurationsinformationen in der Produktionsumgebung landen. In den meisten Fällen kann die Web.config Datei in der Entwicklungsumgebung nicht unverändert in die Produktionsumgebung kopiert werden. Stattdessen muss eine angepasste Version von Web.config in die Produktion hochgeladen werden. In diesem Tutorial werden einige der häufigsten Konfigurationsunterschiede kurz erläutert. Außerdem werden einige Techniken zum Verwalten 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. Bei instance sind die Authentifizierungseinstellungen <authentication> und URL-Autorisierungsregeln, die in den Elementen und <authorization> der Web.config Datei beschrieben sind, unabhängig von der Umgebung in der Regel identisch. Andere Konfigurationsinformationen , z. B. Informationen zu externen Ressourcen, unterscheiden sich jedoch in der Regel je nach Umgebung.

Datenbankverbindungszeichenfolgen sind ein hervorragendes 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 erfolgt über eine Verbindungszeichenfolge. Obwohl es möglich ist, die Datenbank Verbindungszeichenfolge direkt auf den Webseiten oder im Code, der eine Verbindung mit der Datenbank herstellt, hartcodieren, ist es am besten, das Web.config<connectionStrings> -Element so zu platzieren, dass sich die Verbindungszeichenfolge Informationen an einem zentralen, zentralen Ort befinden. Häufig wird während der Entwicklung eine andere Datenbank als in der Produktion verwendet. Daher müssen die Verbindungszeichenfolge Informationen für jede Umgebung eindeutig sein.

Hinweis

In zukünftigen Tutorials wird die Bereitstellung von datengesteuerten Anwendungen erläutert. An diesem Punkt werden die Besonderheiten der Speicherung von Datenbankverbindungszeichenfolgen in der Konfigurationsdatei erläutert.

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 solcher Konfigurationseinstellungen an.

Konfigurationseinstellungen, die sich auf die Leistung auswirken

Wenn eine ASP.NET Seite zum ersten Mal (oder zum ersten Mal nach der Änderung) besucht wird, 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 erzwingen zusätzliche Arbeitsspeicheranforderungen beim Ausführen des Codes. Wenn das debug Attribut auf "true" festgelegt ist, werden alle von zurückgegebenen WebResource.axd Inhalte nicht zwischengespeichert. Dies bedeutet, dass ein Benutzer bei jedem Besuch einer Seite den von WebResource.axdzurückgegebenen statischen Inhalt erneut herunterladen muss.

Hinweis

WebResource.axd ist ein in ASP.NET 2.0 eingeführter integrierter HTTP-Handler, den Serversteuerelemente verwenden, um eingebettete Ressourcen wie Skriptdateien, Bilder, CSS-Dateien und andere Inhalte abzurufen. Weitere Informationen dazu, wie WebResource.axd funktioniert und wie Sie damit von Ihren benutzerdefinierten Serversteuerelementen aus auf eingebettete Ressourcen zugreifen können, finden Sie unter Zugreifen auf eingebettete Ressourcen über eine URL mit WebResource.axd.

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 erklärt wird, dass die Anwendung erst debuggt werden kann, wenn das debug Attribut auf "true" festgelegt ist, und bietet Ihnen an, diese Änderung vorzunehmen.

Das Attribut sollte in einer Produktionsumgebung aufgrund seiner Auswirkungen auf die debug Leistung niemals auf "true" festgelegt werden. Eine ausführlichere Diskussion zu diesem Thema finden Sie in scott Guthries Blogbeitrag Don't Run Production ASP.NET Applications With debug="true" Enabled.

Benutzerdefinierte Fehler und Ablaufverfolgung

Wenn eine nicht behandelte Ausnahme in einer ASP.NET Anwendung auftritt, wird sie bis zur Laufzeit angezeigt, an der eine von drei Dingen geschieht:

  • Eine generische Laufzeitfehlermeldung wird angezeigt. Auf dieser Seite wird der Benutzer darüber informiert, dass ein Laufzeitfehler aufgetreten ist, es werden jedoch keine Details zum Fehler bereitgestellt.
  • Es wird eine Ausnahmedetailsemeldung angezeigt, die Informationen zu der soeben ausgelösten Ausnahme enthält.
  • Es wird eine benutzerdefinierte Fehlerseite angezeigt, bei der es sich um eine ASP.NET Seite handelt, die Sie erstellen und die gewünschte Meldung anzeigt.

Was bei einer nicht behandelten Ausnahme geschieht, hängt vom Abschnitt der Web.config Datei <customErrors>ab.

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

Hinweis

Die Standardeinstellung <customErrors> des Abschnitts zeigt die Ausnahmedetails nur an, wenn die Seite über localhost aufgerufen wird, und zeigt andernfalls die Generische Laufzeitfehlerseite an. Dies ist nicht ideal, aber es ist sicher zu wissen, dass das Standardverhalten keine Ausnahmedetails für nicht lokale Besucher offenlegt. Ein zukünftiges Tutorial untersucht den <customErrors> Abschnitt ausführlicher und zeigt, wie eine benutzerdefinierte Fehlerseite angezeigt wird, wenn ein Fehler in der Produktion auftritt.

Ein weiteres ASP.NET Feature, das während der Entwicklung nützlich ist, ist die Ablaufverfolgung. Falls aktiviert, zeichnet die Ablaufverfolgung Informationen zu jeder eingehenden Anforderung auf und stellt eine spezielle Webseite () bereit, Trace.axdum die details der letzten Anforderungen anzuzeigen. Sie können die Ablaufverfolgung über das <trace> -Element in Web.configaktivieren und konfigurieren.

Wenn Sie die Ablaufverfolgung aktivieren, stellen Sie sicher, dass sie in der Produktion 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 zum Verwalten separater Konfigurationsinformationen

Unterschiedliche Konfigurationseinstellungen in den Entwicklungs- und Produktionsumgebungen erschweren den Bereitstellungsprozess. In den vorherigen beiden Tutorials umfasste der Bereitstellungsprozess das Kopieren aller erforderlichen Dateien aus der Entwicklung in die Produktion, aber dieser Ansatz funktioniert nur, wenn die Konfigurationsinformationen in beiden Umgebungen identisch sind. Es gibt eine Vielzahl von Techniken zum Bereitstellen einer Anwendung mit unterschiedlichen Konfigurationsinformationen. Lassen Sie uns einige dieser Optionen für gehostete Webanwendungen katalogisieren.

Manuelles Bereitstellen der Konfigurationsdatei für die Produktionsumgebung

Der einfachste Ansatz besteht darin, zwei Versionen der Web.config Datei zu verwalten: eine für die Entwicklungsumgebung und eine für die Produktionsumgebung. Die Bereitstellung einer Website in der Produktion umfasst 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 ausgeklügelt, aber er ist einfach zu implementieren, da sich Konfigurationsinformationen selten ändern. Dies eignet sich am besten für Anwendungen mit einem kleinen Entwicklungsteam, die auf einem einzelnen Webserver gehostet werden und deren Konfigurationsinformationen selten geändert werden. Dies ist am haltbarsten, wenn Sie die Anwendungsdateien mithilfe eines eigenständigen FTP-Clients manuell bereitstellen. Wenn Sie das Tool "Website kopieren" oder die Option "Veröffentlichen" von Visual Studio verwenden, müssen Sie vor der Bereitstellung zunächst die bereitstellungsspezifische Web.config Datei mit der produktionsspezifischen Datei austauschen und sie dann nach Abschluss der Bereitstellung wieder austauschen.

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

Die bisherigen Diskussionen gingen von einem Ad-hoc-Build- und Bereitstellungsprozess aus. Viele größere Softwareprojekte verfügen über stärker formalisierte Prozesse, die Open-Source-, heimeigen oder Drittanbietertools verwenden. Für solche Projekte können Sie wahrscheinlich den Build- oder Bereitstellungsprozess anpassen, um die Konfigurationsinformationen entsprechend zu ändern, bevor sie in die Produktion gepusht werden. 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 entsprechenden Konfigurationsinformationen für die Produktion variiert je nach Ihren Tools und Ihrem Workflow stark. Daher werden wir uns nicht weiter mit diesem Thema beschäftigen. Wenn Sie ein beliebtes Buildtool wie MSBuild oder NAnt verwenden, finden Sie Bereitstellungsartikel und Tutorials speziell für diese Tools über eine Websuche.

Verwalten von Konfigurationsunterschieden über das Webbereitstellungsprojekt Add-In

Im Jahr 2006 veröffentlichte Microsoft das Webentwicklungsprojekt Add-In für Visual Studio 2005. 2008 wurde eine Add-In für Visual Studio 2008 veröffentlicht. Diese Add-In ermöglicht es ASP.NET Entwicklern, ein separates Webbereitstellungsprojekt neben ihrem Webanwendungsprojekt zu erstellen, das bei der Erstellung die Webanwendung explizit kompiliert und die Dateien zur Bereitstellung in ein lokales Ausgabeverzeichnis kopiert. Das Webanwendungsprojekt verwendet MSBuild im Hintergrund.

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

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

  • Über Web.config die Dateiabschnittsersetzung, in der Sie den zu ersetzenden Abschnitt und eine XML-Datei angeben, die den Ersetzungstext enthält.
  • Indem Sie einen Pfad zu einer externen Konfigurationsquelldatei angeben. Wenn diese Option ausgewählt ist, kopiert das Webbereitstellungsprojekt eine bestimmte Web.config Datei in das Ausgabeverzeichnis (anstelle der Web.config in der Entwicklungsumgebung verwendeten Datei).
  • Durch Hinzufügen benutzerdefinierter Regeln zur MSBuild-Datei, die vom Webbereitstellungsprojekt verwendet wird.

Erstellen Sie zum Bereitstellen der Webanwendung das Webbereitstellungsprojekt, und kopieren Sie die Dateien aus dem Ausgabeordner des Projekts in die Produktionsumgebung.

Weitere Informationen zur Verwendung des Webbereitstellungsprojekts finden Sie in diesem Artikel Webbereitstellungsprojekte aus der Ausgabe vom April 2007 des MSDN Magazine, oder lesen Sie die Links im Abschnitt Weitere Lektüre am Ende dieses Tutorials.

Hinweis

Sie können das Webbereitstellungsprojekt nicht mit Visual Web Developer verwenden, da das Webbereitstellungsprojekt als Visual Studio-Add-In implementiert ist und die Visual Studio Express Editionen (einschließlich Visual Web Developer) keine Add-Ins unterstützen.

Zusammenfassung

Die externen Ressourcen und das Verhalten einer Webanwendung in der Entwicklung unterscheiden sich in der Regel von denen, wenn sich dieselbe Anwendung in der Produktion befindet. Bei instance unterscheiden sich Datenbankverbindungszeichenfolgen, Kompilierungsoptionen und das Verhalten, wenn eine nicht behandelte Ausnahme auftritt, häufig zwischen Umgebungen. Der Bereitstellungsprozess muss diese Unterschiede berücksichtigen. Wie in diesem Tutorial 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 Webbereitstellungsprojekt Add-In oder einen formalisierten Build- oder Bereitstellungsprozess verwenden, der solche Anpassungen berücksichtigen kann.

Viel Spaß beim Programmieren!

Weitere Informationen

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

ZurückWeiter