Anwendungsmigration

Artikel
04/06/2015

Migration der ASP.NET 1.1-Anwendungen zu Visual Studio 2010

Jonathan Waldman

Wenn Sie bereits seit mehreren Jahren mit ASP.NET arbeiten, haben Sie wahrscheinlich auch mit Visual Studio 2003 Anwendungen für Microsoft .NET Framework 1.1 geschrieben. Seit einigen Jahren gibt es nun die neuen, funktionsreichen .NET Framework-Versionen 2.0, 3.0 und 3.5, und Sie haben sich vielleicht schon gefragt, ob es sinnvoll und machbar wäre, bewährte Anwendungen für Framework 1.1 auf eine dieser Versionen zu aktualisieren.

Heute setzen immer mehr Entwickler auf der ganzen Welt verstärkt auf die neue Version, .NET Framework 4, und Sie sehen sich eventuell noch stärker gedrängt, eine Migration in Angriff zu nehmen. Sollten Sie sich zu diesem Schritt entschließen, finden Sie bei Microsoft nützliche Tools, die Ihnen die Modernisierung Ihrer ASP.NET-Anwendungen erleichtern, sodass diese die neuesten .NET Framework-Innovationen nutzen können. Insbesondere möchte ich Ihnen zeigen, wie Sie ASP.NET 1.1-Anwendungen durch die Migration zu Visual Studio 2010 (Professional, Premium oder Ultimate) neu beleben und auf .NET Framework 2.0, 3.0, 3.5 oder 4 ausrichten können.

Warum migrieren?

Selbst wenn es Ihnen nur darum geht, vorhandene ASP.NET 1.1-Websites zu pflegen, schwinden die Möglichkeiten hinsichtlich Support und Erweiterbarkeit. Als 1.1-Entwickler sollte es Ihnen zu denken geben, dass Microsoft den grundlegenden Support für Visual Studio 2003 am 14. Oktober 2008 eingestellt hat und zudem keine weiteren Service Packs für Visual Studio 2003 und für .NET Framework 1.1 mehr zur Verfügung stellen wird. (Den erweiterten Support für Visual Studio 2003 bietet Microsoft allerdings bis zum 8. Oktober 2013 an.)

Wirklich beunruhigen müsste Sie jedoch die Tatsache, dass eine wachsende Zahl von Drittanbietern keine Komponenten mehr anbietet bzw. unterstützt, die unter .NET Framework 1.1 ausgeführt werden können oder die Visual Studio 2003-IDE erweitern. Sie sollten sich darauf einstellen, dass Ihre .NET Framework 1.1-Webanwendungen und auch die Visual Studio 2003-IDE langsam veralten.

Es gibt jedoch noch eine Vielzahl anderer Gründe für eine Migration. .NET Framework, die Programmiersprachen C# und Visual Basic .NET sowie die Visual Studio-IDE bieten mittlerweile eine Vielzahl von Verbesserungen. Die Migration Ihrer .NET 1.1-Websites auf die Version .NET 2.0 oder höher (im Folgenden als 2.0+ bezeichnet) wäre eine ideale Gelegenheit, die neuesten Tools und Technologien sowie die in modernen Sprachen und Frameworks verfügbaren Features (wie Masterseiten, AJAX, Windows Communication Foundation [WCF], Silverlight, LINQ, partielle Klassen, Generika, Lambda-Ausdrücke und anonyme Methoden), wie sie von führenden .NET-Entwicklern bereits genutzt werden, zur Aufwertung Ihrer Websites zu nutzen. Generell gilt: Je höher die Frameworkversion, auf die Sie Ihre ASP.NET-Anwendungen ausrichten, desto mehr Möglichkeiten und Leistung stehen Ihnen zur Verfügung. Fundierten Support erhalten Sie dabei nicht nur von Microsoft selbst (zum Zeitpunkt dieses Artikels bietet Microsoft grundlegenden Support für alle Framework 2.0+-Versionen an), sondern auch in aktiven Entwicklerforen und über Tools von Drittanbietern. Zudem sind Bücher zu allen Aspekten der neuesten Technologien allgemein erhältlich, und auf vielen Websites werden videobasierte Kurse, Blogs, Whitepapers und weitere Schulungsoptionen angeboten.

Die neueste, hochentwickelte Visual Studio 2010-IDE ist für sich genommen schon fast ein ausreichender Grund für eine Migration. Sie ist der Visual Studio 2003-IDE um mehrere Generationen voraus, unterstützt neue Features wie IntelliTrace und kann mit einer Vielzahl leistungsstarker Plug-Ins von Drittanbietern erweitert werden. Damit sind neue Produktivitätsmaßstäbe bei der Programmierung praktisch garantiert. Einige wenige Benutzer werden aus verschiedenen Gründen weiterhin ältere Versionen von Visual Studio verwenden müssen, doch im Prinzip macht Visual Studio 2010 die Verwendung paralleler Installationen von Visual Studio 2005 und Visual Studio 2008 praktisch überflüssig, da mit Visual Studio 2010 alle Framework 2.0+-Versionen als Ziel festgelegt werden können. Doch wie in Visual Studio
2005 und Visual Studio 2008 ist in Visual Studio 2010 die Ausrichtung auf Framework 1.1 nicht möglich. Sie müssen also weiterhin Visual Studio 2003 verwenden oder Ihre ASP.NET 1.1-Projekte zu einer neueren Frameworkversion migrieren.

Bedenken sollten Sie außerdem, dass Entwickler, die ausschließlich Erfahrung mit Framework 1.1 vorweisen können, auf dem Markt weniger gefragt sind als solche, die sich auch mit Framework 2.0+-Versionen auskennen. Angesichts der Lage auf dem Arbeitsmarkt für Entwickler ist es ganz in Ihrem Interesse, sich alle nur möglichen Vorteile zu sichern. Mit der Nutzung neuer Framework-Features in Ihrem Anwendungscode verbessern Sie Ihre Glaubwürdigkeit und Ihre Chancen als professioneller Softwareentwickler.

Migrationsprobleme

Warum haben sich also noch nicht alle Entwickler für die Migration zu einer höheren Version als ASP.NET 1.1 entschieden, wo doch seit Visual Studio 2003 bereits mehrere neue Versionen von Visual Studio und .NET Framework veröffentlicht wurden? Ein Hindernis stellt die Implementierung der in Visual Studio 2005 bereitgestellten Migrationsoption für ASP.NET 1.1 zu ASP.NET 2.0 dar. Das klingt nicht wirklich abschreckend, aber bei der Einführung von Visual Studio 2005 mussten ASP.NET 1.1-Projekte in einen ganz neuartigen Webprojekttyp konvertiert werden. Die Architektur, auf der ASP.NET 1.1-Websites aufgebaut waren, musste also sorgfältig überarbeitet und ausführlichen Regressionstests unterzogen werden. Bei diesem Prozess mussten die Websites praktisch neu geschrieben werden, und vielen Entwicklern schienen die Kosten und die technischen Herausforderungen zu hoch. Daher wurde häufig entschieden, bestehende ASP.NET 1.1-Websites unverändert zu lassen.

Die Herausforderungen bei der Migration von ASP.NET 1.1 zu ASP.NET 2.0 werden besser verständlich, wenn man bedenkt, dass die Struktur aller ASP.NET 1.1-Webprojekte auf einer projektbezogenen Datei-/Ordnerkonfiguration basiert. Dieser Projekttyp wurde ursprünglich als „2003-Webprojektmodell“ bezeichnet und ist heute als Webanwendungsprojekt (WAP) bekannt. Mit der Veröffentlichung von Visual Studio 2005 führte Microsoft einen neuen ordnerbezogenen, auf .NET Framework 2.0 ausgelegten Projekttyp ein. Dieser Projekttyp wurde ursprünglich als „2005-Webprojektmodell“ bezeichnet und ist heute als Websiteprojekt (WSP) bekannt. (Lassen Sie sich hierdurch nicht verwirren. Beachten Sie einfach die alphabetische Reihenfolge der Akronyme: WAP kommt vor WSP, Visual Studio 2003 vor Visual Studio 2005.)

Ausführliche Erläuterungen zu WAPs und WSPs würden den Rahmen dieses Artikels sprengen. Nur soviel: Ursprünglich war Microsoft davon ausgegangen, dass alle migrierten Webanwendungen der Version 1.1 mit dem mitgelieferten Konvertierungs-Assistenten letztlich zu WSPs konvertiert würden. Besorgte Entwickler legten jedoch sofort Protest ein, da der ursprüngliche WAP-Projekttyp im Hinblick auf Technik und Leistung eine Reihe von Vorteilen bot, die dem neuen WSP-Projekttyp fehlten. Entwickler, Manager und andere Beteiligte stellten zudem fest, dass Microsoft lediglich eine Migrationsoption für ASP.NET 1.1-WAPs zu ASP.NET 2.0-WSPs zur Verfügung gestellt hatte, die sich insbesondere für Websites mit einem gewissen Grad an Komplexität als zeitaufwändig und teuer erwies. Dies sorgte in der ASP.NET-Entwicklercommunity schnell für Aufregung. Detaillierte Erläuterungen zu den technischen Problemen bei einer solchen Migration würden einen eigenen mehrteiligen Artikel in Anspruch nehmen. Bei Interesse an den Details ist der Artikel „Häufig auftretende Probleme bei der Webprojektkonvertierung und entsprechende Lösungen“ (msdn.microsoft.com/library/aa479312) aus der MSDN Library zu empfehlen.

Microsoft reagierte glücklicherweise schnell und stellte schon in Visual Studio 2005 SP1 eine überarbeitete Version des Konvertierungs-Assistenten bereit. Mit dieser Version des Assistenten ließ sich ein ASP.NET 1.1-WAP in ein ASP.NET 2.0-WAP konvertieren. Doch viele Entwickler erfuhren nichts von dieser neuen Migrationsoption und beschäftigten sich daher nie damit. In Visual Studio 2010 können Sie mit dem Konvertierungs-Assistenten ein ASP.NET 1.1-WAP in ein ASP.NET 2.0+-WAP konvertieren. Hierbei weist 2.0+ darauf hin, dass ein solches Projekt nach der Konvertierung auf 2.0, 3.0, 3.5 oder 4 ausgerichtet werden kann. So können auch ältere Webanwendungen noch konvertiert werden. Für die Konvertierung einer ASP.NET 1.1-Anwendung in eine WSP-Anwendung können Sie den Konvertierungs-Assistenten aus Visual Studio 2010 nicht verwenden (es wäre auch gar nicht sinnvoll). Hierfür würden Sie den Konvertierungs-Assistenten benötigen, der in der Visual Studio 2005-Version vor SP1 enthalten war.

Von Interesse ist eventuell auch, dass Sie beim Erstellen eines neuen Projekts in Visual Studio 2010 zwischen einem WAP und einem WSP wählen können. Microsoft hat die Unterstützung für WAPs und WSPs in aktuellen und allen zukünftigen .NET Framework-Versionen zugesichert.

Der Prozess

Bei der Migration von ASP.NET 1.1-Anwendungen mit Visual Studio 2010 sind die folgenden Schritte auszuführen, die später näher erläutert werden:

Ausführen des Konvertierungs-Assistenten
Festlegen des Zielframeworks und der Startseite
Kompilieren und Beheben von Fehlern
Konvertieren von Seiten und Benutzersteuerelementen in partielle Klassen
Kompilieren und Beheben von Fehlern

Ausführen des Konvertierungs-Assistenten Damit Sie den Konvertierungs-Assistenten zur Konvertierung eines 1.1-WAP in ein 2.0+-WAP verwenden können (was hier das Ziel ist), müssen Sie beim Visual Studio 2010-Setup Visual Web Developer als Option installieren. Wenn Sie das nicht getan haben, müssen Sie Visual Studio 2010 Setup mit der Option „Microsoft Visual Studio 2010 ändern oder entfernen“ erneut ausführen. Wählen Sie „Features hinzufügen oder entfernen“, und stellen Sie sicher, dass das Kontrollkästchen für das Feature „Visual Web Developer“ aktiviert ist (siehe Abbildung 1).

image: Ensure the Visual Web Developer Component Is Installed Before Launching the Conversion Wizard

Abbildung 1 Überprüfen der Installation von Visual Web Developer vor dem Starten des Konvertierungs-Assistenten

Auch wenn Visual Web Developer nicht installiert ist, lässt sich der Konvertierungs-Assistent starten und ausführen, und mit Ausnahme des Webprojekts können Sie damit alle Projekte in einer Projektmappe konvertieren. Sie werden darauf hingewiesen, dass zur Konvertierung des Webprojekts Visual Web Developer installiert werden muss.

Bevor Sie eine Konvertierung in Angriff nehmen, sollten Sie sicherstellen, dass die Anwendung nicht nur erstellt und ausgeführt werden kann, sondern auch möglichst weitgehend bereinigt und möglichst gut strukturiert ist. Führen Sie deshalb folgende Schritte aus:

Bereinigen Sie die Anwendung. Löschen Sie nicht verwendete oder nicht benötigte Dateien, sodass Ihre Webanwendung letztlich nur die wesentlichen Komponenten enthält.
Vergewissern Sie sich, dass alle Projekte in der Projektmappe ohne Kompilierungsfehler kompiliert werden können.
Ich würde Ihnen empfehlen, die Projektmappe zur Quellcodeverwaltung hinzuzufügen, sofern sie nicht bereits so konfiguriert ist. Auf jeden Fall sollten Sie jedoch sicherstellen, dass keine Dateien exklusiv aus dem Repository ausgecheckt sind. Wenn Sie die Projektmappe zur Quellcodeverwaltung hinzufügen, können Sie nach Abschluss der Konvertierung bestimmte vom Assistenten vorgenommene Änderungen untersuchen.
Stellen Sie sicher, dass keine Dateien oder Ordner, die nicht der Quellcodeverwaltung unterliegen, als schreibgeschützt gekennzeichnet sind. Nur dann kann der Assistent diese Dateien bzw. Ordner bei Bedarf aktualisieren.
Erstellen Sie eine Sicherungskopie. Wenn Sie die Projektmappe auf einem virtuellen Computer ausführen, empfiehlt es sich, einfach den gesamten virtuellen Computer zu sichern oder eine Momentaufnahme davon zu erstellen. Sichern Sie andernfalls die gesamte Anwendung einschließlich aller Abhängigkeiten. Wenn Sie unsicher sind, welche Abhängigkeiten bestehen, können Sie in der Projektmappendatei (SLN-Datei) oder in den einzelnen Projektdateien (PROJ-Dateien) nachschauen. Hierbei handelt es sich um Textdateien, die Sie visuell überprüfen können. Viele ASP.NET-Anwendungen enthalten Projekte, die auf Netzwerkspeicherorte oder auf Ordner außerhalb der Webstammverzeichnisse bzw. Webanwendungsordner verweisen. Wenn diese Abhängigkeiten nicht gesichert werden, können erhebliche Probleme entstehen, falls Sie die Anwendung jemals anhand der Sicherungsdateien wiederherstellen möchten. Denken Sie daran, dass im Rahmen des vollständigen Migrationsprozesses Änderungen an allen Projekten in der Anwendung vorgenommen werden. Es ist daher sehr vorteilhaft, sich vorab mit den Anwendungsabhängigkeiten vertraut zu machen. Bedenken Sie auch Folgendes: Projekte, die in mehreren ASP.NET 1.1-Anwendungen verwendet werden, können nach der Migration der Projektmappe nicht mehr in Visual Studio 2003 geöffnet werden. Wenn Sie in einem Team arbeiten, wirken sich Änderungen, die Sie an gemeinsam genutzten Projekten vornehmen, auch auf die Projektmappen anderer Teammitglieder aus, denn die verweisen dann möglicherweise auf konvertierte Projekte. Unabhängig davon, ob Projekte in mehreren Anwendungen oder innerhalb von Teams gemeinsam verwendet werden, sollten Sie gemeinsam genutzte Projekte entkoppeln, indem Sie davon Kopien erstellen. Stellen Sie dann sicher, dass auf Ihrer Entwicklungsarbeitsstation eine lokale Kopie vorhanden ist. Beim Verschieben eines Projekts (z. B. zum Entkoppeln) ändert sich die Projektmappendatei. Sie sollten deshalb eine Sicherungskopie der Projektmappendatei erstellen, bevor Sie an den Projekten, auf die diese verweist, Änderungen vornehmen. Eine weitere Sicherungskopie sollten Sie erstellen, nachdem Sie die Projektabhängigkeiten entkoppelt haben und bevor Sie den Konvertierungs-Assistenten ausführen. Nach Abschluss des Konvertierungsprozesses finden Sie außerdem möglicherweise noch Fehler in den ursprünglichen Projektmappendateien. Mit einer vor der Konvertierung erstellten Sicherungskopie der Projektmappe können Sie solche Fehler problemlos beheben und dann den Konvertierungs-Assistenten erneut ausführen.
Ziehen Sie die Einrichtung einer parallelen Umgebung in Erwägung: Da Visual Studio 2003 und Visual Studio 2010 parallel auf demselben Computer ausgeführt werden können, lassen sich ASP.NET 1.1- und ASP.NET 2.0+-Websites parallel ausführen. Dies erleichtert die QA-Tests nach der Migration.

Zum Starten des Assistenten öffnen Sie die Visual Studio 2003-Projektmappendatei. Klicken Sie dazu in Visual Studio 2010 im Menü „Datei“ auf „Öffnen“ und dann auf „Projekt/Projektmappe“. Wenig später wird das Willkommensfenster des Visual Studio-Konvertierungs-Assistenten (siehe Abbildung 2) angezeigt. Klicken Sie auf „Weiter“.

image: The Visual Studio Conversion Wizard Introductory Dialog

Abbildung 2 Willkommensfenster des Visual Studio-Konvertierungs-Assistenten

Wenn während der Verarbeitung durch den Konvertierungs-Assistenten Probleme erkannt werden, möchten Sie vielleicht die Projektmappe anhand einer Sicherungskopie wiederherstellen, Änderungen daran vornehmen und dann den Prozess neu starten. In diesem Schritt können Sie ganz einfach eine Sicherungskopie erstellen (siehe Abbildung 3). Allerdings werden dabei alle Abhängigkeiten der Projektmappe im angegebenen Sicherungsordner gespeichert. Für eine ordnungsgemäße Wiederherstellung müssen Sie daher unbedingt die ursprüngliche Struktur der gesicherten Ordner kennen.

image: The Conversion Wizard Gives You an Opportunity to Create a Backup Before Proceeding

Abbildung 3 Erstellen einer Sicherungskopie über den Konvertierungs-Assistenten

Wenn in diesem Schritt eine Sicherungskopie der Projektmappe erstellt werden soll, geben Sie einfach einen Ordnerpfad an. Der Assistent erstellt einen untergeordneten Ordner namens „Backup“, in dem die Dateien der Projektmappe gespeichert werden. Jedes Projekt in der Projektmappe wird in einem entsprechenden Unterordner des Ordners „Backup“ gesichert, selbst wenn es nicht aus dem Stammordner der Projektmappe stammt. Damit die Sicherung ordnungsgemäß ausgeführt werden kann, müssen die Projektnamen in der Projektmappe also unbedingt eindeutig sein. Klicken Sie auf „Weiter“.

Daraufhin wird ein letztes Dialogfeld mit Hinweisen zur Quellcodeverwaltung und zu Lese-/Schreibberechtigungen angezeigt (siehe Abbildung 4).

image: The Conversion Wizard Advises You Before Letting You Continue

Abbildung 4 Wichtige Hinweise im Konvertierungs-Assistenten vor dem nächsten Schritt

Wenn Sie sich für eine Sicherung entscheiden, werden der angeforderte Sicherungstyp und der Speicherort für die Sicherungsdateien angezeigt. Außerdem wird eine Zusammenfassung der zu konvertierenden Projektmappe sowie aller zugehörigen Projekte angezeigt. Klicken Sie auf „Fertig stellen“, wenn die Angaben richtig sind.

Jetzt werden Sie möglicherweise zur Eingabe von Anmeldeinformationen für das Repository der Quellcodeverwaltung (z. B. Visual SourceSafe) aufgefordert, damit das Projekt ausgecheckt werden kann.

Beim Konvertieren der Projekte in der Projektmappe wird eine Statusanzeige angezeigt. Dieser Prozess kann mehrere Minuten in Anspruch nehmen, da der Assistent die Projekte in der Projektmappe mehrmals verarbeitet.

Im Konvertierungs-Assistenten wird die Meldung angezeigt, dass der erste Schritt abgeschlossen ist und dass jetzt die Webanwendung konvertiert werden muss (siehe Abbildung 5).

image: The Conversion Wizard Lets You Know that You Will Need to Convert Your Web Project in Order to Complete the Migration

Abbildung 5 Hinweis im Konvertierungs-Assistenten zur Konvertierung des Webprojekts zum Abschließen der Migration

Danach werden Sie darüber informiert, dass der anfängliche Prozess abgeschlossen ist (siehe Abbildung 6).

image: The Conversion Wizard Alerts You When the Conversion Is Complete

Abbildung 6 Benachrichtigung zum Abschluss der Konvertierung im Konvertierungs-Assistenten

Das Konvertierungsprotokoll können Sie mit der Vorlage „Konvertierungsbericht“ überprüfen. Diese Datei, UpgradeLog.XML, finden Sie in demselben Ordner, in dem sich auch die SLN-Datei der Projektmappe befindet. Aus dem Upgradeprotokoll geht hervor, welche Projektdateien konvertiert wurden. Außerdem enthält es alle relevanten Fehler und Warnmeldungen. Schließlich finden Sie dort nützliche Kommentare sowie Kommentare zu der Frameworkversion, auf die die einzelnen Projekte ausgerichtet sind. Abbildung 7 zeigt einen Auszug aus einem solchen Bericht.

image: The Conversion Log Shows Details About the Converted Web Application

Abbildung 7 Konvertierungsprotokoll mit Details zur konvertierten Webanwendung

Überprüfen Sie alle Warnungen und Fehler. Warnungen (wie eine Änderung am relativen Pfad eines Sicherungspfads) beziehen sich im Allgemeinen auf weniger gravierende technische Probleme. Normalerweise können Sie die konvertierte Projektmappe erfolgreich kompilieren, ohne irgendwelche Maßnahmen zu ergreifen. Fehlermeldungen (wie ein fehlender Dateiverweis) erfordern dagegen eine sorgfältige Überprüfung und entsprechende Maßnahmen, denn diese beziehen sich üblicherweise auf Probleme, die eine erfolgreiche Kompilierung der konvertierten Projektmappe verhindern. Bei einer großen Anzahl an Fehlern finden Sie im Konvertierungsprotokoll hilfreiche Erläuterungen zu den erforderlichen Maßnahmen. Viele zusätzliche Informationen finden Sie normalerweise auch in den Hilfedateien zu Visual Studio 2010 sowie auf verschiedenen technischen Websites. In manchen Fällen kann es sinnvoll sein, die im Konvertierungsprotokoll aufgeführten Fehler in den ursprünglichen Visual Studio 2003-Projektdateien und nicht in der konvertierten Projektmappe zu beheben. Hierbei erweist sich die zuvor erstellte Sicherungskopie als sehr nützlich. Modifizieren Sie einfach Ihre Visual Studio 2003-Projektmappe, und führen Sie dann den Konvertierungs-Assistenten erneut aus.

Nachdem Sie alle Warnungen überprüft und alle Fehler behoben haben, können Sie die letzten Fenster des Konvertierungs-Assistenten schließen. Der Konvertierungs-Assistent ist damit abgeschlossen. Ihre Projektmappendatei (SLN-Datei) und die zugehörigen Projektdateien (PROJ-Dateien) liegen jetzt im Visual Studio 2010-Format vor. Zum Abschließen der Migration sind jedoch noch einige weitere Schritte auszuführen.

Festlegen des Zielframeworks und der Startseite Nach der Ausführung des Konvertierungs-Assistenten ist Ihr Visual Studio 2003-Webprojekt für die Ausführung unter .NET Framework 4 konfiguriert, die anderen Projekte der Projektmappe jedoch für die Ausführung unter .NET Framework 2.0. Es ist zwar möglich, verschiedene Frameworkversionen zu verwenden, es empfiehlt sich jedoch, für alle Projekte in einer Projektmappe nur ein Zielframework festzulegen, sofern nicht Einschränkungen Ihres Webhostingunternehmens oder die Unternehmensinfrastruktur dagegen sprechen. (In Visual Studio 2010 wechseln die IDE-Features je nach dem Zielframework des aktiven Projekts. Bei auf verschiedene Frameworkversionen ausgerichteten Projekten ist das Verhalten der IDE beim Wechsel zwischen den Projekten daher möglicherweise verwirrend. Wenn für alle Projekte dieselbe Zielframeworkversion gilt, ist die IDE-Benutzeroberfläche dagegen für alle Projekte konsistent, und Sie brauchen bei der Programmierung nur ein konsistentes Framework zu berücksichtigen.)

Sie können für konvertierte Projekte ein anderes Zielframework festlegen, indem Sie einfach im Projektmappen-Explorer mit der rechten Maustaste auf den Projektstamm klicken und „Eigenschaften“ wählen. Daraufhin wird eine Konfigurationsseite angezeigt (siehe Abbildung 8). Wählen Sie dort die Registerkarte „Anwendung“, und geben Sie für „Zielframework“ eine der Framework 2.0+-Versionen an.

image: Change the Target Framework for Any Project to 2.0, 3.0, 3.5 or 4

Abbildung 8 Ändern des Zielframeworks für ein Projekt in 2.0, 3.0, 3.5 oder 4

Legen Sie zuletzt die Startseite für Ihr Webprojekt fest. Suchen Sie dazu im Projektmappen-Explorer die Seite, klicken Sie mit der rechten Maustaste darauf, und wählen Sie die Option „Als Startseite festlegen“ aus.

Kompilieren und Beheben von Fehlern Nachdem Sie die Projektmappe und die Projektdateien auf das Visual Studio 2010-Format aktualisiert haben, können Sie das ASP.NET 2.0+-WAP kompilieren. Damit alle Projekte in der Projektmappe erstellt werden, empfiehlt es sich, die Kompilierung in Visual Studio 2010 auszuführen. Klicken Sie dazu im Menü „Erstellen“ auf „Projektmappe neu erstellen“. Nach dem erneuten Erstellen können Sie alle Buildprobleme im Fenster „Fehlerliste“ überprüfen. Klicken Sie zum Aufrufen des Fensters im Menü „Ansicht“ auf „Fehlerliste“. Im Fenster „Fehlerliste“ werden Fehler, Warnungen und Meldungen angezeigt. Welche dieser Elemente im Fenster angezeigt werden, können Sie festlegen, indem Sie die entsprechenden Schaltflächen für Fehler, Warnungen und Meldungen ein-/ausschalten. In Visual Studio 2010 werden normalerweise klare Anweisungen zum Beheben der im Fenster „Fehlerliste“ aufgeführten Probleme angezeigt. Wenn Sie einen Fehler, eine Warnung oder eine Meldung nicht verstehen, markieren Sie einfach die entsprechende Zeile im Fenster „Fehlerliste“ und drücken dann <F1>. Daraufhin wird ein Hilfefenster mit näheren Informationen zu dem Problem angezeigt. Wenn die Hilfe nicht lokal installiert ist, können Sie sie über das Internet anzeigen. Die meisten angezeigten Fehler dürften sich auf Änderungen am Framework beziehen, die zu Namenskonflikten mit Ihrem eigenen Code führen. Diese lassen sich normalerweise beheben, indem Sie Ihre Verweise mit einem Namespace vollqualifizieren. Die meisten angezeigten Warnungen dürften auf veraltete Mitglieder zurückzuführen sein. Sie können veraltete Mitglieder weiterhin verwenden, doch bedenken Sie, dass diese in der nächsten Version von .NET Framework wahrscheinlich nicht mehr unterstützt werden. Wenn veraltete Mitglieder angezeigt werden und 2.0 als Zielframework festgelegt ist, können Sie diese Mitglieder wahrscheinlich nicht mehr verwenden, sobald Sie zu Version 3.x oder 4 als Zielframework wechseln.

Das Beheben der im Fenster „Fehlerliste“ aufgeführten Probleme dürfte einige Zeit in Anspruch nehmen. Bevor Sie mit den nächsten Schritten fortfahren, sollten Sie alle der in Fehlern und die meisten oder alle der in Warnungen aufgeführten Probleme lösen.

Konvertieren von Seiten und Benutzersteuerelementen in partielle Klassen Im nächsten Schritt führen Sie den Befehl „In Webanwendung konvertieren“ aus. Sie können diesen Befehl für eine einzelne Seite oder ein einzelnes Steuerelement ausführen, um einen Eindruck von den damit vorgenommenen
Änderungen zu gewinnen. Schneller geht es jedoch, wenn Sie ihn für die gesamte Projektmappe ausführen. Klicken Sie dazu im Projektmappen-Explorer mit der rechten Maustaste auf den Knoten „Projektmappe“, und wählen Sie dann „In Webanwendung konvertieren“ aus. Bei diesem Prozess geschieht Folgendes:

Durch Hinzufügen eines neuen Designerdokuments für Seiten und Benutzersteuerelemente werden partielle Klassen implementiert.
Das AutoEventWireup-Attribut für Seiten und Benutzersteuerelemente wird festgelegt.
Für alle Steuerelemente auf Seiten und für Benutzersteuerelemente werden deklarative Ereignishandler hinzugefügt.

ASP.NET 1.1-Anwendungen weisen CodeBehind-Module auf („aspx.cs“ und „ascx.cs“ für C# sowie „aspx.vb“ und „ascx.vb“ für Visual Basic .NET), die vom Entwickler geschriebenen und vom Web Form-Designer generierten Code enthalten. Wenn Sie in Visual Studio 2003 Seiten oder Benutzersteuerelemente erstellen und mit dem Web Form-Designer Steuerelemente hinzufügen, fügt die IDE geschützte Instanzfelder zu Ihren CodeBehind-Modulen hinzu, sodass Sie auf diese zusätzlichen Steuerelemente verweisen können. Nachdem der Befehl „In Webanwendung konvertieren“ ausgeführt wurde, erscheint für jede Seite und jedes Benutzersteuerelement ein Designerdokument. Im Projektmappen-Explorer wird diese Datei jedoch nur angezeigt, wenn die Option „Alle Dateien anzeigen“ aktiviert ist. Die Namen der Designerdateien sind mit den Namen der entsprechende Seite bzw. des entsprechenden Benutzersteuerelements identisch und weisen die Erweiterung „designer.cs“ (C#) bzw. „designer.vb“ (Visual Basic .NET) auf.

Wenn Sie z. B. in C# eine Seite mit dem Namen „MyPage.aspx“ erstellt haben, gibt es jetzt ein neues Dokument mit dem Namen „MyPage.aspx.designer.cs“. Dieses Designerdokument enthält geschützte Instanzfelder, die zuvor im CodeBehind-Modul enthalten waren. Diese Felder wurden in das Designermodul verschoben und sind daher jetzt von Ihrem eigenen Code getrennt. Das ist möglich, weil es sich bei Designermodulen um partielle Klassen handelt. Das bedeutet, dass mit dem Befehl „In Webanwendung konvertieren“ auch der CodeBehind-Code für die entsprechende Seite bzw. das entsprechende Benutzersteuerelement in eine partielle Klasse umgewandelt wird.

Instanzfelder in C# und Visual Basic .NET erscheinen beispielsweise in den CodeBehind-Dokumenten von Visual Studio 2003-Projekten wie folgt:

[VB]
Protected WithEvents MyButton As System.Web.UI.WebControls.Button

[C#]
protected System.Web.UI.WebControls.Button MyButton;
The CWA command moves each to a corresponding designer file:
[VB]
Protected WithEvents MyButton As Global.System.Web.UI.WebControls.Button

[C#]
protected global::System.Web.UI.WebControls.Button MyButton;

(global:: zeigt an, dass die Suche nach dem System-Namespace auf der globalen Namespaceebene starten sollte. Damit ist sichergestellt, dass der System-Namespace des Frameworks nicht durch Ihren eigenen System-Namespace verdeckt wird.)

Die Designerdatei wird dynamisch erstellt und kann jederzeit erneut generiert werden. Sie können also die Dokumente „designer.cs“ und „designer.vb“ problemlos löschen und neu generieren bzw. wiederherstellen, wenn sie fehlen, indem Sie im Projektmappen-Explorer einfach mit der rechten Maustaste auf den Seiten- oder Benutzersteuerelementknoten klicken und den Befehl „In Webanwendung konvertieren“ erneut ausführen. Mit dem Befehl „In Webanwendung konvertieren“ wird das HTML-Markup für eine Seite bzw. ein Benutzersteuerelement nach Serversteuerelementen durchsucht, und danach werden in der Designerdatei für die partielle Klasse die erforderlichen Instanzvariablen generiert. Danach werden alle Instanzvariablen gelöscht, die noch in Ihrer eigenen CodeBehind-Datei („aspx.cs“, „ascx.cs“, „aspx.vb“ oder „ascx.vb“) enthalten sind.

Bei partiellen Klassen kann der Quellcode für eine Klasse, Struktur oder Schnittstelle über zwei oder mehr Dateien innerhalb eines Namespace verteilt sein. Der Compiler fügt diese partiellen Definitionen später zu einer einzigen Deklaration für den jeweiligen Typ zusammen. In Visual Studio dienen partielle Klassen weiterhin zunächst dazu, vom Entwickler geschriebenen Code sauber von Code zu trennen, der durch die IDE generiert wurde. Insbesondere bei der Arbeit in Teams werden diese Klassen von Entwicklern jedoch auch in eigenen CodeBehind-Modulen genutzt.

Da partielle Klassen in ASP.NET 2.0+-Anwendungen die Norm darstellen, sollten Sie Ihre ASP.NET 1.1-Klassen in partielle Klassen aufteilen. Wenn Sie diesen Schritt auslassen, funktionieren Ihre Seiten und Benutzersteuerelemente zwar weiterhin, aber beim Modifizieren der Steuerelemente auf einer Seite (ASPX-Datei) oder in einem Benutzersteuerelement (ASCX-Datei) müssen Sie die Steuerelementfeld-Deklarationen in den CodeBehind-Dateien manuell aktualisieren.

Der Befehl „In Webanwendung konvertieren“ ändert außerdem den Wert des AutoEventWireup-Attributs sowie die Art und Weise, wie Ereignisse deklariert und verknüpft werden. Die Auswirkungen dieser Änderungen sind erheblich und sollen im Folgenden näher erläutert werden. Mit dem booleschen AutoEventWireup-Attribut wird festlegt, ob Ereignishandler für das Page-Objekt implizit (Wert „True“) oder explizit (Wert „False“) verknüpft werden. Bei Seiten wird das AutoEventWireup-Attribut im @Page-Tag, bei Benutzersteuerelementen im @Control-Tag festgelegt. Mit dem Befehl „In Webanwendung konvertieren“ wird das AutoEventWireup-Attribut für C#-Seiten und ‑Benutzersteuerelemente auf „True“, für Visual Basic .NET-Seiten und ‑Benutzersteuerelemente auf „False“ festgelegt.

Entwickler haben ihre Vorlieben, und so ist es durchaus möglich, dass das AutoEventWireup-Attribut für bestimmte Seiten und Benutzersteuerelemente in einer ASP.NET 1.1-Anwendung auf „True“ oder „False“ oder auch gar nicht festgelegt wird. Ist Letzteres der Fall, so wird der Standardwert aus der web.config-Datei oder, falls darin nicht enthalten, aus der machine.config-Datei übernommen. Dabei müssen Sie Folgendes bedenken: Der AutoEventWireup-Wert kann sich nach Ausführung des Befehls „In Webanwendung konvertieren“ ändern. Diese Änderung kann zu unerwartetem Verhalten führen. So kann es z. B. vorkommen, dass Seitenereignisse zweimal ausgelöst werden. Dieses Phänomen tritt besonders häufig auf, wenn Sie für Page-Objektereignisse in einer ASP.NET 1.1-Anwendung eigene Benennungskonventionen erstellt haben. Ein Beispiel hierfür ist der folgende C#-Code, in dem ein Page_Load2-Handler mit dem Page.Load-Ereignisdelegaten verknüpft wird:

this.Load += new System.EventHandler(this.Page_Load2);

Wenn das AutoEventWireup-Attribut auf „False“ festgelegt ist, wird das Ereignis wie erwartet einmal ausgelöst, und zwar selbst dann, wenn es eine CodeBehind-Funktion namens Page_Load gibt. Wenn das AutoEventWireup-Attribut dagegen auf „True“ festgelegt ist, werden beide Ereignisse ausgelöst, einmal für den hier gezeigten expliziten Verknüpfungscode und einmal für den impliziten Verknüpfungscode, mit dem der Page_Load-Ereignishandler das Page.Load-Ereignis abonniert. Sehen Sie sich den Code in Abbildung 9 an.

Abbildung 9 Testen des AutoEventWireup-Verhaltens

public partial class _Default : System.Web.UI.Page
{
  override protected void OnInit(EventArgs e)
  {
    InitializeComponent();
    base.OnInit(e);
  }

  private void InitializeComponent()
  {
    this.Load += new System.EventHandler(this.Page_Load2);
  }

  protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

  protected void Page_Load2(object sender, EventArgs e)
  {
    Response.Write("In Page_Load2().<br />");
  }
}

Der Code in Abbildung 9 generiert die folgende Ausgabe:

In Page_Load().
In Page_Load2().
Top of Form 1
Bottom of Form 1

Das Gleiche geschieht in Visual Basic .NET, wenn das AutoEventWireup-Attribut auf „True“ festgelegt ist. Betrachten Sie den folgenden Code:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)

  Response.Write("In Page_Load.<br />")

End Sub

Private Sub Page_Load2(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles MyBase.Load

  Response.Write("In Page_Load2.<br />")

End Sub

Wenn das AutoEventWireup-Attribut auf „True“ festgelegt ist, werden beide Ereignishandler ausgelöst, und die Seite wird angezeigt:

In Page_Load2.
  In Page_Load.

Wie Sie sehen, werden zwei Ereignishandler ausgeführt, und die Reihenfolge der Ausführung entspricht – wie bei allen Multicastdelegaten – möglicherweise nicht dem, was Sie erwarten. Beachten Sie schließlich noch Folgendes: Wenn das AutoEventWireup-Attribut auf „True“ festgelegt ist, werden Seitenereignishandler mit dem richtigen Funktionsnamen, wie z. B. Page_Load, unabhängig davon ausgelöst, ob sie mit oder ohne Argumente definiert sind. Zum Beispiel:

protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

Dies ist identisch mit Folgendem:

protected void Page_Load(object sender, EventArgs e)
  {
    Response.Write("In Page_Load().<br />");
  }

Wenn beide Handler vorhanden sind, wird nur der Handler mit Argumenten ausgelöst. Dies ist ein weiterer Aspekt, den Sie bei der Problembehandlung berücksichtigen müssen. Seien Sie daher beim Testen von Seiten und Benutzersteuerelementen vorsichtig, insbesondere, wenn der AutoEventWireup-Wert durch den Befehl „In Webanwendung konvertieren“ geändert wurde.

Schließlich wird mit dem Befehl „In Webanwendung konvertieren“ expliziter C#- und Visual Basic .NET-Code entfernt, der Steuerelementereignisse verknüpft. Stattdessen werden im Markup für die Seite bzw. das Benutzersteuerelement deklarative Ereignisattribute verwendet. So gibt es beispielsweise in ASP.NET 1.1 für das Klickereignis einer Schaltfläche im CodeBehind normalerweise einen Ereignishandler wie den folgenden:

this.MyButton.Click += new System.EventHandler(this.MyButton_Click);

Der Befehl „In Webanwendung konvertieren“ entfernt diesen und fügt stattdessen ein OnClick-Attribut für die Serversteuerelement-Deklaration hinzu:

<asp:Button ID="MyButton" runat="server" Text="MyButton" onclick="MyButton" />

In Visual Basic .NET werden keine deklarativen Ereignisse hinzugefügt. Stattdessen wird das Handles-Schlüsselwort zum CodeBehind hinzugefügt. Das Markup für eine Schaltfläche sieht daher folgendermaßen aus:

<asp:Button ID="MyButton" runat="server" Text="Button" />

Die Verknüpfung des Steuerelements mit dem Handler erfolgt hierbei über den CodeBehind:

Protected Sub MyButton_Click(
  ByVal sender As Object, ByVal e As EventArgs) _
Handles MyButton.Click

End Sub

Ereignisdelegaten für diese deklarativen Ereignishandlerkonstrukte werden zur Kompilierzeit erstellt.

Kompilieren und Beheben von Fehlern Die Migration ist jetzt abgeschlossen. Es empfiehlt sich, die Projektmappe neu zu erstellen und alle restlichen in Compilerfehlern bzw. Warnungen genannten Probleme zu überprüfen und gegebenenfalls zu beheben. Beachten Sie, dass Kompilierungsfehler behoben werden müssen, bevor Sie das Webprojekt erstellen und die migrierte Website in einem Browser anzeigen können. Auch bei der Kompilierung erzeugte Warnungen sollten Sie überprüfen. Diese Probleme sind jedoch nicht kritisch und verhindern die Verwendung der Webanwendung nicht. Halten Sie zudem alle Compilermeldungen fest, denn dort finden Sie normalerweise hilfreiche Empfehlungen zu Verbesserungen, die Sie implementieren sollten, wenn die Zeit es zulässt. Darüber hinaus müssen Sie Regressions- und QA-Tests für den migrierten Code ausführen. Stellen Sie insbesondere sicher, dass Ereignisse wie erwartet ausgelöst werden.

Überlegungen nach der Migration

Das ASP.NET-Projekt ist jetzt auf ein neueres Framework ausgerichtet und wird unter einer moderneren Version der IDE ausgeführt. Daher sind einige weitere Aspekte zu beachten.

Wenn Sie eine ASP.NET 1.1-Anwendung von einem 32-Bit- zu einem 64-Bit-Betriebssystem migriert haben, beachten Sie, dass IIS 6.0 und höher sowohl den 32-Bit- als auch den 64-Bit-Betriebsmodus unterstützen. Da ASP.NET 1.1 nur im 32-Bit-Modus ausgeführt werden kann, kann die konvertierte ASP.NET-Anwendung noch 32-Bit-Abhängigkeiten (wie COM- oder P/Invoke-Aufrufe) enthalten, die nach der Migration möglicherweise nicht mehr richtig funktionieren. Zur Behebung dieses Problems rufen Sie für die Anwendung unter „Anwendungspool“ die Option „Erweiterte Einstellungen“ auf und legen „32-Bit-Anwendungen aktivieren“ auf „True“ fest.

Visual Studio 2010 erwartet XHTML-konforme Webseiten. Aus ASP.NET 1.1 konvertierte Seiten sind dies aber wahrscheinlich nicht. Zu den meisten Seiten dürfte es daher XHTML-Validierungswarnungen geben. Diese können Sie anzeigen, indem Sie die Seite im Quell- oder Entwurfsmodus aufrufen und dann im Menü „Ansicht“ auf „Fehlerliste“ klicken. Die entsprechenden Seiten können zwar trotzdem ausgeführt werden, doch die Warnungen weisen darauf hin, dass sie in modernen Browsern möglicherweise nicht richtig gerendert werden. Wenn die Zeit es zulässt, sollten Sie die Seiten und Benutzersteuerelemente im Hinblick auf XHTML-Konformität aktualisieren, damit sie in modernen Browsern richtig gerendert werden. Wenn eine Webanwendung speziell auf einen älteren Browser ausgerichtet ist oder gerade keine Zeit ist, sich mit Markupvalidierungsfehlern zu beschäftigen, können Sie eine andere Option für die Markupvalidierung wählen. Klicken Sie dazu im Menü „Extras“ auf „Optionen“, wechseln Sie zum Knoten „Texteditor“, und legen Sie für „Ziel“ die Option „Internet Explorer 6“ fest (siehe Abbildung 10). Dieses Vorgehen eignet sich nur für Entwickler, die eine Anwendung auf Internet Explorer 6 ausrichten müssen. Dies kann z. B. bei unternehmensinternen Intranetanwendungen der Fall sein. Damit gilt für die Renderingvalidierung eine ähnliche Ebene wie die, die Sie wahrscheinlich in Visual Studio 2003 verwendet haben.

image: You Can Suppress XHTML Validation Errors by Changing the HTML Validation Target to Internet Explorer 6

Abbildung 10 Unterdrücken von XHTML-Validierungsfehlern durch Festlegen von Internet Explorer 6 als Ziel für die HTML-Validierung

Bei Anwendungen, die in anderen Browsern als Internet Explorer oder in höheren Internet Explorer-Versionen als Version 6 richtig angezeigt werden müssen, sollten Sie die XHTML-Markupfehler im HTML-Editor weiter anzeigen lassen. Verwenden Sie außerdem die neue controlRenderingCompatibilityVersion-Konfigurationseinstellung in .NET Framework 4. Diese steht als Eigenschaft im system.web-Abschnitt der web.config-Datei zur Verfügung:

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
</system.web>

Wenn controlRenderingCompatibilityVersion nicht in der Web.config-Datei festgelegt ist, gilt die gerade ausgeführte Version von ASP.NET als Standardwert. Sie können als controlRenderingCompatibilityVersion-Wert „3.5“ oder „4.0“ festlegen. Im Konvertierungs-Assistenten wird „3.5“ als Wert festgelegt, sodass Seiten wie in ASP.NET 3.5 gerendert werden. Mit dieser Einstellung legen Sie fest, wie in den ASPX-Dateien angegebenes Markup im Browser letztlich gerendert wird. Hier ein Beispiel aus der Visual Studio 2010-Onlinehilfe: Wenn controlRenderingCompatibilityVersion auf „3.5“ festgelegt ist, rendert ein serverseitiges ASP.NET-Steuerelement des Typs „Label“, dessen IsEnabled-Eigenschaft auf „False“ festgelegt ist, ein HTML-Element des Typs „span“, dessen „disabled“-Attribut auf „disabled“ festgelegt ist. Wenn controlRenderingCompatibilityVersion auf „4.0“ festgelegt ist, enthält das span-Element stattdessen ein „class“-Attribut mit einem Verweis auf eine CSS-Klasse.

Beachten Sie, dass bei der Einstellung „4.0“ modernes XHTML-Markup generiert wird. Damit werden möglicherweise Clientskript- oder CSS-Regeln verletzt, die in der ASP.NET 1.1-Version der Seite ordnungsgemäß funktioniert haben, was sich wiederum auf das Verhalten und/oder die Ästhetik des gerenderten Inhalts auswirken kann. Solange eventuell Gründe gegen die Generierung von gültigem XHTML-Code sprechen, empfiehlt es sich, controlRenderingCompatibilityVersion auf „3.5“ festzulegen. Bei der Einstellung „3.5“ (und nur bei dieser) ist xhtmlConformance zu beachten. Mögliche Werte hierfür sind „Legacy“, „Strict“ und „Transitional“ (Standardwert). Bei „Strict“ wird XHTML 1.0 Strict-Markup gerendert, bei „Transitional“ XHTML 1.0 Transitional-Markup. Bei „Legacy“ wird HTML-Markup gerendert, das dem in ASP.NET 1.1 gerenderten Markup ähnelt, damit aber nicht unbedingt identisch ist:

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
  <xhtmlConformance mode="Transitional"/>
</system.web>

Erfahrungsgemäß empfiehlt es sich, den Modus „Legacy“ zu vermeiden, da sonst das UpdatePanel von ASP.NET AJAX möglicherweise nicht richtig funktioniert. Beachten Sie auch, dass der controlRenderingCompatibilityVersion-Wert den DOCTYPE der Webseite nicht ändert, sondern nur die Art und Weise, wie ASP.NET-Steuerelemente gerendert werden. Ob Seiten richtig gerendert werden, hängt also von den Werten für controlRenderingCompatibilityVersion, xhtmlConformance und DOCTYPE sowie dem Typ und der Version des verwendeten Zielbrowsers ab.

Beachten Sie außerdem folgenden Aspekt: Eventuell möchten Sie das virtuelle Verzeichnis ändern, unter dem die neu migrierte Website ausgeführt wird, insbesondere, wenn sie parallel zur ASP.NET 1.1-Version ausgeführt werden soll. Klicken Sie dazu mit der rechten Maustaste im Projektmappen-Explorer auf das Webprojekt, wählen Sie „Eigenschaften“, und rufen Sie dann die Registerkarte „Web“ auf. Unter „Server“ gibt es die Option „Lokalen IIS-Webserver verwenden“. Stellen Sie sicher, dass diese Option aktiviert ist, geben Sie eine Projekt-URL an (wie z. B. http://localhost/mysitemigrated), und klicken Sie auf die Schaltfläche „Virtuelles Verzeichnis erstellen“, wenn das virtuelle Verzeichnis noch nicht vorhanden ist.

In ASP.NET 1.1-Anwendungen wird der Windows-Benutzer ASPNET zum Zuweisen von Berechtigungen für Dateien und Ordner unter dem virtuellen Stammverzeichnis verwendet. In ASP.NET 2.0+ wird dagegen der NETZWERKDIENST-Benutzer verwendet. Diese Rechte müssen dem NETZWERKDIENST-Benutzer gewährt werden, wenn ASP.NET in Ihrer Anwendung Schreibzugriff auf bestimmte Dateien oder Ordner benötigt. Wenn Sie sich jemals unsicher sind, welcher Benutzer diese Zugriffsrechte benötigt, können Sie die ASP.NET-Anwendung und dann den Benutzernamen am Wert der Envionment.UserName-Eigenschaft ablesen.

Bei Add-Ons von Drittanbietern oder Abhängigkeiten (ob als Binär- oder Quellcode) sollten Sie sich beim Anbieter nach der neuesten Version erkundigen. Die Bibliothek des beliebten Protokollierungsprogramms NLog ist beispielsweise als Build 1.1 und 2.0 verfügbar. Besorgen Sie sich am besten gleich Build 2.0, dann brauchen Sie den Code aus Build 1.1 nicht selbst zu migrieren. Auch die Anbieter von produktivitätssteigernden Add-Ons für die Visual Studio-IDE bieten Updates für diese Produkte an. Verwenden Sie für die neue Visual Studio 2010-IDE unbedingt die jeweils neueste Version solcher Produkte.

Nach der Migration von ASP.NET 1.1-Webanwendungen profitieren Sie von zwei unmittelbaren Vorteilen. Erstens benötigen Sie für Ihre Website nicht länger Front Page Server Extensions (FPSE). Wahlweise können Sie allerdings weiterhin damit arbeiten. Zweitens muss IIS nicht mehr auf dem Entwicklungscomputer installiert sein, denn ASP.NET Development Server ist in Visual Studio 2010 integriert. Sie können zwar Visual Studio 2003 ASP.NET- und Visual Studio 2010 ASP.NET-Anwendungen weiterhin parallel ausführen (z. B. zu QA-/Debuggingzwecken), doch für die konvertierte Visual Studio 2010 ASP.NET-Anwendung ist Visual Studio 2003 oder der Zugriff auf .NET Framework 1.1 nicht länger erforderlich.

Als C#-Entwickler bemerken Sie wahrscheinlich, dass im Entwurfsmodus Seiten- und Benutzersteuerelementereignisse im Fenster „Eigenschaften“ nicht mehr mithilfe des gelben Blitzsymbols angezeigt werden können. Wenn Sie diese Ereignisse in Visual Studio 2003 anzeigen/erstellen möchten, klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Datei (ASPX-Datei) oder das Benutzersteuerelement (ASCX-Datei) und wählen dann „Komponenten-Designer anzeigen“ aus. Daraufhin wird ein Fenster „Eigenschaften“ angezeigt, das die bekannte Liste mit Ereignissen enthält. Durch Doppelklicken auf eins der Ereignisse in der Liste können Sie eine eigene Ereignisprozedur und Delegatenverknüpfungscode (wird zur InitializeComponent-Funktion hinzugefügt) erstellen.

Sobald die Website gehostet werden soll, müssen Sie wissen, welche CLR benötigt wird. Bei .NET Framework 3.0 und 3.5 wird die Website unter CLR 2.0, bei .NET Framework 4 unter CLR 4.0 ausgeführt. Zum Hosten einer ASP.NET 4.0-Anwendung muss das Hostingunternehmen also CLR 4.0 unterstützen.

Ich hoffe, ich konnte Ihnen hiermit aufzeigen, wie Sie Ihre Visual Studio 2003 ASP.NET-Anwendungen zu Visual Studio 2010 migrieren können. Nachdem Sie diese Aufgabe einmal bewältigt haben, stehen Ihnen ganz neue Programmiertechnologien zur Verfügung. Ich bin überzeugt, dass sich die Umstellung auf diese neue Technologie relativ problemlos bewerkstelligen lässt und dass Sie diese Entscheidung nicht bereuen werden.

Jonathan Waldman hat bereits für das PC Magazine geschrieben und nutzt als führender Microsoft Certified Professional die .NET Framework-Technologien zur Erstellung kundenspezifischer Softwarelösungen für den Desktop und das Web. Sie erreichen ihn unter jonathan.waldman@live.com.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Scott Hanselman