Share via

Allgemeine Konfigurationsunterschiede zwischen Entwicklungs- und Produktionsumgebungen (C#)

  • 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 kopieren. 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 beschrieben. Im Tutorial 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 Bereitstellen Ihrer Website mithilfe von Visual Studio wurde die Bereitstellung mithilfe des Tools zum Kopieren von Websites von Visual Studio und der Option Veröffentlichen untersucht. 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. Es beschreibt auch das Verhalten der Anwendung in bestimmten Situationen, z. B. den Handlungsverlauf, der bei einer nicht behandelten Ausnahme ausgeführt werden soll.

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. Für instance sind die Authentifizierungseinstellungen <authentication> und URL-Autorisierungsregeln, die in den Elementen und <authorization> elementen der Web.config Datei beschrieben sind, in der Regel unabhängig von der Umgebung identisch. Andere Konfigurationsinformationen – z. B. Informationen zu externen Ressourcen – unterscheiden sich jedoch 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 zuerst eine Verbindung herstellen, und dies erfolgt über eine Verbindungszeichenfolge. Obwohl es möglich ist, die Datenbank Verbindungszeichenfolge direkt auf den Webseiten oder dem Code, der eine Verbindung mit der Datenbank herstellt, hart zu codieren, ist es am besten, ihr Web.config<connectionStrings> Element so zu platzieren, dass sich die Verbindungszeichenfolge Informationen an einem 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 untersucht. An diesem Punkt werden wir uns mit den Besonderheiten der Speicherung von Datenbankverbindungszeichenfolgen in der Konfigurationsdatei befassen.

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 debuggen. In der Produktionsumgebung wird dieselbe Anwendung von vielen verschiedenen gleichzeitigen Benutzern besucht. ASP.NET enthält eine Reihe von Features, die Entwickler beim Testen und Debuggen einer Anwendung unterstützen, 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 ihr deklaratives Markup in eine Klasse konvertiert werden, und diese Klasse muss kompiliert werden. Wenn die Webanwendung die automatische Kompilierung verwendet, muss auch die Code-Behind-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, was bedeutet, dass ein Benutzer bei jedem Besuch einer Seite den von zurückgegebenen WebResource.axdstatischen 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 sie funktioniert und wie Sie damit auf eingebettete Ressourcen über Ihre benutzerdefinierten Serversteuerelemente zugreifen können, finden Sie unter Zugreifen auf eingebettete Ressourcen über eine URL mit WebResource.axd.

Das <compilation> Attribut des debug Elements wird normalerweise 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 nicht debuggen kann, bis das debug Attribut auf "true" festgelegt ist, und bietet an, diese Änderung für Sie 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 im Blogbeitrag von Scott Guthrie: Produktion nicht ausführen ASP.NET Anwendungen mit debug="true" Aktiviert.

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:

  • Es wird eine generische Laufzeitfehlermeldung angezeigt. Auf dieser Seite wird der Benutzer darüber informiert, dass ein Laufzeitfehler aufgetreten ist, aber keine Details zum Fehler.
  • Es wird eine Ausnahmedetailsemeldung angezeigt, die Informationen zu der soeben ausgelösten Ausnahme enthält.
  • Es wird eine benutzerdefinierte Fehlerseite angezeigt. Dabei handelt es sich um eine ASP.NET Seite, 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 wenig 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 Standardabschnittseinstellung <customErrors> zeigt die Meldung "Ausnahmedetails" nur an, wenn die Seite über localhost aufgerufen wird, andernfalls die Fehlerseite für die generische Laufzeit. Dies ist nicht ideal, aber es ist sicher, 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. Die Ablaufverfolgung zeichnet, sofern aktiviert, Informationen zu jeder eingehenden Anforderung auf und stellt eine spezielle Webseite bereit, Trace.axdum aktuelle Anforderungsdetails 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 war der Bereitstellungsprozess mit dem Kopieren aller erforderlichen Dateien aus der Entwicklung in die Produktion verbunden. Dieser Ansatz funktioniert jedoch 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. Das Bereitstellen eines Standorts in der Produktion beinhaltet das Kopieren aller Dateien auf den Produktionsserver in der Entwicklungsumgebung mit Ausnahme der Web.config Datei. Stattdessen wird die produktionsumgebungsspezifische Web.config Datei in die Produktion kopiert.

Dieser Ansatz ist nicht sehr anspruchsvoll, aber leicht zu implementieren, da sich Konfigurationsinformationen selten ändern. Dies funktioniert am besten für Anwendungen mit einem kleinen Entwicklungsteam, die auf einem einzelnen Webserver gehostet werden und deren Konfigurationsinformationen selten geändert werden. Am haltbarsten ist die manuelle Bereitstellung der Anwendungsdateien mithilfe eines eigenständigen FTP-Clients. Wenn Sie das Tool "Website kopieren" oder die Option "Veröffentlichen" von Visual Studio verwenden, müssen Sie zuerst die bereitstellungsspezifische Web.config Datei durch die produktionsspezifische Datei austauschen, bevor sie bereitgestellt werden, und sie dann nach Abschluss der Bereitstellung wieder austauschen.

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

Die bisherigen Diskussionen gehen von einem Ad-hoc-Build- und Bereitstellungsprozess aus. Viele größere Softwareprojekte verfügen über formalisierte Prozesse, die Open-Source-Tools, selbst entwickelte Tools oder Drittanbieter-Tools nutzen. Für solche Projekte können Sie wahrscheinlich den Build- oder Bereitstellungsprozess anpassen, um die Konfigurationsinformationen entsprechend zu ändern, bevor sie in die Produktion übertragen 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 Tools und 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 bereitstellungsspezifische Artikel und Tutorials 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. Ein Add-In für Visual Studio 2008 wurde 2008 veröffentlicht. Mit diesem Add-In können ASP.NET Entwickler neben ihrem Webanwendungsprojekt ein separates Webbereitstellungsprojekt erstellen, das 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 die

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 dann die Dateien aus dem Ausgabeordner des Projekts in die Produktionsumgebung.

Weitere Informationen zur Verwendung des Webbereitstellungsprojekts finden Sie in diesem Artikel Zu Webbereitstellungsprojekten in der April 2007-Ausgabe 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 ausnahme nicht behandelt wird, in den einzelnen 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 behandelten Themen finden Sie in den folgenden Ressourcen:

ZurückWeiter