Übersicht über die Migration zu ASP.NET 2.0
Aktualisiert: November 2007
Viele der in früheren Versionen von ASP.NET verwendeten Programmierkonzepte bleiben in ASP.NET Version 2.0 gleich. Daher ist das Entwickeln von Anwendungen in ASP.NET 2.0 für Benutzer von ASP.NET 1.x ein vertrauter Vorgang. ASP.NET 2.0 wird unter denselben Betriebssystemen und mit derselben Hardware ausgeführt, die Sie zum Ausführen von ASP.NET 1.x-Anwendungen verwenden, z. B. Microsoft Windows 2000 und Microsoft Internetinformationsdienste (IIS) 5.0, Microsoft Windows XP und IIS 5.1 sowie Microsoft Windows Server 2003 und IIS 6.0.
Wenn Sie eine vorhandene Webanwendung zu ASP.NET migrieren möchten, sollten Sie sich vor der Migration über die neuen Features von ASP.NET 2.0 informieren. Zu den wichtigsten Änderungen zählen das Code-Behind-Modell für Seiten, die Webanwendungs-Ordnerstruktur und das Seitenkompilierungsmodell.
Stellen Sie vor dem Migrieren sicher, dass die ASP.NET 1.x-Anwendung in der .NET Framework-Version, für die es entwickelt wurde, kompiliert und ausgeführt werden kann. Stellen Sie weiterhin vor der Migration sicher, dass Microsoft .NET Framework Version 2.0 installiert ist und funktioniert.
Dieses Thema enthält allgemeine Hinweise, die vor dem Migrieren berücksichtigt werden sollten. In den folgenden Abschnitten dieses Themas werden folgende Aspekte erörtert:
Vorteile des Migrierens
Seitenmodelle
Gemeinsame Verwendung von Daten in verschiedenen ASP.NET-Versionen
Gemeinsame Formularauthentifizierung in verschiedenen ASP.NET-Versionen
Namenskonflikte
Markupkompatibilität
HttpOnly und siteübergreifende Skripterstellung
Vorteile des Migrierens
Das Migrieren von Webanwendungen zu ASP.NET 2.0 bietet viele Vorteile, z. B. bessere Trennung von Markup und Code, reservierte Anwendungsordner und automatische Codekompilierung.
Das neue, auf Teilklassen basierende Code-Behind-Modell ermöglicht eine stärkere Trennung von Markup und Code, und in den Code-Behind-Dateien sind weder Steuerelementdeklarationen noch Ereignisverknüpfungscode erforderlich. Im Seitenkompilierungsmodell von ASP.NET werden die Code-Behind-Dateien bei der ersten Anforderung der entsprechenden ASPX-Dateien zur Laufzeit zu mehreren Assemblys kompiliert.
In ASP.NET wird jetzt eine optimierte Webanwendungsstruktur verwendet, die auf reservierten Ordnern basiert. Diese Ordner enthalten spezifische Inhalte, damit Sie die Anwendung effizienter strukturieren können. Der Inhalt einiger reservierter Ordner, z. B. App_Data, wird nicht als Antwort auf Webanforderungen bereitgestellt. Mit Anwendungscode kann jedoch auf diese Ordner zugegriffen werden. Weitere Informationen hierzu finden Sie unter ASP.NET-Websitestruktur.
Wenn eine Ressource auf Ihrer Website angefordert wird, kompiliert der ASP.NET 2.0-Compiler automatisch den Anwendungscode und die abhängige Ressourcen. So können Änderungen einer vorhandenen Webseite oder abhängiger Ressourcen in ASP.NET 2.0 einfach gespeichert werden, da die Seite und die zugehörigen Ressourcen bei der nächsten Anforderung der Seite neu kompiliert werden. Dies gilt für Ressourcen wie Codedateien im Ordner App_Code, Ressourcendateien in den Ordnern App_GlobalResources und App_LocalResources sowie für Designs im Ordner App_Themes. Weitere Informationen zum Seitenkompilierungsmodell finden Sie unter Übersicht über die ASP.NET-Kompilierung.
Wenn Sie eine umfangreiche Anwendung migrieren, sollten Sie Visual Web Developer 2005, Visual Web Developer 2005 Express Edition, Visual Studio 2005 oder Visual Studio 2005 Team System verwenden. Jede dieser Anwendungen enthält einen Migrations-Assistenten, der viele Aufgaben, die bei einer Migration i. d. R. anfallen, automatisch ausführt. Der Assistent führt die Änderungen aus, die zum Konvertieren von ASP.NET 1.x-Webanwendungen in ASP.NET 2.0 erforderlich sind.
Webanwendungen müssen nicht migriert werden, da ASP.NET 2.0 in hohem Grad abwärtskompatibel mit früheren Versionen ist. Wenn Sie keine Migration ausführen, können Sie dennoch viele Features von ASP.NET 2.0 in der Webanwendung nutzen, solange die Anwendung .NET Framework 2.0 verwendet. Informationen über das Konfigurieren einer vorhandenen Webanwendung für die Verwendung von .NET Framework 2.0 finden Sie unter Gewusst wie: Ausführen von ASP.NET 1.x-Anwendungen in .NET Framework 2.0.
Seitenmodelle
Das Code-Behind-Modell von ASP.NET für Webseiten ermöglicht, das Markup einer Webseite in einer Datei (der ASPX-Datei) und den Programmcode in einer anderen Datei (der Code-Behind-Datei) zu speichern. Das Code-Behind-Modell für ASP.NET 2.0 unterscheidet sich von früheren Versionen durch ein neues Sprachfeature, das als partielle Klassen bezeichnet wird. Das neue Code-Behind-Modell in ASP.NET 2.0 ermöglicht eine noch stärkere Trennung von Markup und Code als frühere Versionen von ASP.NET.
Webseiten, die das alte, auf dem CodeBehind-Attribut der @ Page-Direktive beruhende Code-Behind-Modell verwenden, können auch in ASP.NET 2.0 ausgeführt werden. Jedoch wird empfohlen, diese Seiten mit dem CodeFile-Attribut der @ Page-Direktive und einer Teilklassendefinition in der Code-Behind-Datei zu dem neuen Code-Behind-Modell zu migrieren, um die optimierte Trennung von Markup und Code sowie die automatische Seitenkompilierung nutzen zu können. Webseiten, die das alte Code-Behind-Modell verwenden, müssen manuell kompiliert werden.
Sie können die Änderungen wie in Gewusst wie: Migrieren einer ASP.NET 1.1-Webseite mit dem CodeBehind-Attribut zu ASP.NET 2.0 beschrieben manuell durchführen, oder Sie können eine der Microsoft Visual Studio 2005-Editionen wie Visual Web Developer 2005 Express Edition verwenden, die einen Migrationsassistenten beinhalten.
ASP.NET, Version 1.1, unterstützt außerdem eine Variante des Code-Behind-Modells, in der das CodeBehind-Attribut der @ Page-Direktive durch das Src-Attribut ersetzt wurde. Webseiten, die das Src-Attribut verwenden, werden auch in ASP.NET 2.0 ausgeführt und erfordern für ihre Ausführung keine Änderung.
Das Einzeldatei-Seitenmodell ist eine Alternative zum Code-Behind-Modell. In diesem Modell werden Markup und Programmcode der Seite in der gleichen physikalischen ASPX-Datei abgelegt. Einzeldateiseiten aus früheren Versionen von ASP.NET können ohne Änderung in ASP.NET 2.0 ausgeführt werden.
Gemeinsame Verwendung von Daten in verschiedenen ASP.NET-Versionen
Sie können einige Teile einer Website zu ASP.NET 2.0 migrieren und andere Teile unverändert lassen. Wenn die Website in unabhängige Webanwendungen unterteilt ist, die gemeinsam die Funktionalität der Website bereitstellen, können Sie auch lediglich einen Teil der Anwendungen migrieren. In diesem Szenario ist es nicht möglich, einen gemeinsamen Anwendungszustand für migrierte Anwendungen und nicht migrierten Anwendungen zu verwenden. Auch der Sitzungszustand wird nicht anwendungsübergreifend verwendet, es sei denn, Sie stellen eine benutzerdefinierte Lösung für den Sitzungszustand bereit, auf die sowohl von ASP.NET 1.x-Seiten als auch von ASP.NET 2.0-Seiten zugegriffen werden kann. Weitere Informationen hierzu finden Sie unter Implementieren eines Sitzungszustandsspeicher-Anbieters.
Gemeinsame Formularauthentifizierung in verschiedenen ASP.NET-Versionen
Die Formularauthentifizierung stellt Ihnen eine Möglichkeit zur Verfügung, Benutzer mit eigenem Code zu authentifizieren und anschließend ein Authentifizierungstoken in einem Cookie oder im Seiten-URL beizubehalten. Die ASP.NET-Formularauthentifizierung kann anwendungsübergreifend in verschiedenen ASP.NET-Versionen ausgeführt werden, sodass von einer Version ausgegebene Authentifizierungstickets von einer anderen Version genutzt werden können.
Das Konfigurieren der Authentifizierung für die Ausführung in verschiedenen ASP.NET-Versionen ähnelt dem Konfigurieren der Authentifizierung für ein Netzwerk von Webservern (eine Webfarm). In beiden Fällen legen Sie das validationKey-Attribut und das decryptionKey-Attribut des machineKey-Elements für die Anwendungen fest, die Authentifizierungstickets mit demselben Schlüssel gemeinsam verwenden. Um versionsübergreifende Authentifizierung in verschiedenen ASP.NET-Versionen zu unterstützen, müssen Sie eine zusätzliche Konfigurationsänderung vornehmen, indem Sie in der Datei Web.config der ASP.NET 2.0-Anwendung das decryption-Attribut des machineKey-Elements auf 3DES festlegen. Die Standardverschlüsselung für ASP.NET 2.0 ist AES, wohingegen in früheren Versionen von ASP.NET 3DES verwendet wurde. Weitere Informationen hierzu finden Sie unter Übersicht über die ASP.NET-Formularauthentifizierung.
Namenskonflikte
Vor dem Migrieren empfiehlt es sich, die Webanwendung auf Namen zu überprüfen, die zu einem Konflikt mit Featureklassen und -Namespaces in .NET Framework 2.0 führen. Konflikte können auftreten, wenn in der Webanwendung übliche Namen wie z. B. Cache, Mitgliedschaft, Profil oder Rolle verwendet werden, die bereits in .NET Framework verwendet werden. Um Namenskonflikte zu vermeiden, suchen Sie im Code nach Verweisen auf entsprechende Namen, und verwenden Sie einen voll qualifizierten Verweis.
In ASP.NET 2.0 wird ein anderes Websitelayout als in früheren Versionen verwendet. Um das Arbeiten mit Webanwendungen zu erleichtern, sind bestimmte Ordner- und Dateinamen in ASP.NET reserviert. Sie können sie für spezifische Inhalte verwenden. Inhalt in reservierten Ordnern wird für Webanforderungen dieses Inhalts nicht bereitgestellt. Dies kann in der vorhandenen Anwendung zu Problemen führen. Daher sollten Sie vor dem Migrieren einzelner Anwendungsdateien die Namen von Anwendungsordnern oder -dateien ändern, die zu einem Konflikt mit den Namen reservierter Ordner und Dateien von ASP.NET 2.0 führen. Weitere Informationen zu den reservierten Ordnern in ASP.NET-Websitelayouts finden Sie unter ASP.NET-Websitelayout.
Markupkompatibilität
Sämtliches Markup, das von ASP.NET und den mit ASP.NET gelieferten Webserversteuerelementen erzeugt wird, entspricht nun standardmäßig dem XHTML 1.0 Transitional-Standard. Dies kann nach der Migration zu Problemen mit dem HTML-Rendering führen. Um die Migration einer Webanwendung zu erleichtern, können Sie in der Datei Web.config das mode-Attribut des xhtmlConformance-Elements auf Legacy festlegen. Dies sollte ein temporärer Schritt im Migrationsvorgang sein. Langfristig empfiehlt es sich, die Anwendung mit dem auf Transitional festgelegten mode-Attribut des xhtmlConformance-Elements auszuführen. Darüber hinaus wird empfohlen, den migrierten Seiten das DOCTYPE-Element hinzuzufügen. Weitere Informationen zu den Vorteilen von XHTML-konformen Webseiten finden Sie unter ASP.NET und XHTML.
HttpOnly und siteübergreifende Skripterstellung
.NET Framework 2.0 bietet die neue HttpOnly-Eigenschaft in der HttpCookie-Klasse Das Festlegen dieser Eigenschaft auf true kann das dargestellte Sicherheitsrisiko durch siteübergreifende Skripts verringern. Die HttpOnly-Eigenschaft wird für Formularauthentifizierungscookies und Sitzungs-ID-Cookies automatisch auf true festgelegt, sodass diese Cookies für clientseitige Skripts nicht verfügbar sind. Wenn auf einer migrierten Webseite eine NullReferenceException-Ausnahme auftritt, kann dies darauf hinweisen, dass die Clientsitzung aufgrund der auf true festgelegten HttpOnly-Eigenschaft beendet wurde. Verwenden Sie in diesem Fall eine der folgenden Lösungen:
Legen Sie in der Datei Global.asax im EndRequest-Ereignishandler der HttpApplication-Klasse die HttpOnly-Eigenschaft der einzelnen Cookies auf false fest.
Schreiben Sie ein benutzerdefiniertes Modul zum Kopieren des Cookies in ein anderes Cookie und zum Löschen der HttpOnly-Eigenschaft, um so Änderungen durch Clientskripts zu ermöglichen.
Schreiben Sie einen benutzerdefinierten Sitzungs-ID-Manager, der die HttpOnly-Eigenschaft nicht auf true festlegt.
Weitere Informationen zum Verringern des Sicherheitsrisikos durch siteübergreifende Skripts finden Sie unter Mitigating Cross-site Scripting with HTTP-only Cookies.
Siehe auch
Konzepte
Übersicht über Webanwendungsprojekte
Übersicht über die ASP.NET-Formularauthentifizierung