Einführung in Webanwendungsprojekte.
Veröffentlicht: 10. Apr 2006 | Aktualisiert: 10. Jul 2006
Von Microsoft Corporation
Erfahren Sie mehr zur Verwendung des neuen Projekttyps Webanwendungsprojekt, der nun als Alternative zu dem in Visual Studio 2005 bereits verfügbaren Websiteprojekt zur Verfügung steht.
Auf dieser Seite
Einführung
Zweck der Webanwendungsprojekte
In diesem Artikel
Installieren von Webanwendungsprojekten
Vergleich von Websiteprojekten und Webanwendungsprojekten
Szenario 1: Erstellen eines neuen Webanwendungsprojekts
Schritt 1: Erstellen eines neuen Projekts
Schritt 2: Öffnen und Bearbeiten der Seite
Schritt 3: Erstellen und Ausführen des Projekts
Festlegen von Build- und Bereitstellungseigenschaften für Webanwendungsprojekte
Anpassen der Bereitstellungsoptionen für Webanwendungsprojekte
Szenario 2: Migrieren eines Visual Studio .NET 2003-Webprojekts zu einem Webanwendungsprojekt
Schritt 1: Installieren der Vorabversion für Visual Studio 2005-Webanwendungsprojekte
Schritt 2: Sichern der Visual Studio .NET 2003-Projekte
Schritt 3: Öffnen und Überprüfen des Visual Studio .NET 2003-Webprojekts
Schritt 4: Migrieren der Lösung zu Visual Studio 2005
Schritt 5: Überprüfen in Visual Studio 2005
Schritt 6: Konvertieren von Codebehind-Klassen in partielle Klassen
Schritt 7: Untersuchen und Beheben von XHTML-Kompatibilitätsproblemen
Die Zukunft von Webanwendungsprojekten
Anhang A: Bekannte Probleme
Problem 1: Datenszenarios
Problem 2: Visual Basic-Inlinecode wird möglicherweise nicht ordnungsgemäß konvertiert
Problem 3: WSE und Webanwendungsprojekte
Problem 4: Konvertieren des Starter Kits für Vereinswebsites (Visual Basic)
Problem 5: Konvertieren des Starter Kits für persönliche Websites (Visual Basic)
Problem 6: Konvertieren eines Visual Studio 2005-Websiteprojekts in ein Webanwendungsprojekt
Einführung
Das Add-In für Webanwendungsprojekte ergänzt Visual Studio 2005 um die Option für ein Webprojektmodell, das dem Visual Studio .NET 2003-Webprojektmodell entspricht. In diesem Artikel wird der neue Projekttyp als Webanwendungsprojekt bezeichnet. Webanwendungsprojekte können als Alternative zu den bereits in Visual Studio 2005 verfügbaren Websiteprojekt-Modellen (in diesem Artikel als Websiteprojekte bezeichnet) verwendet werden.
Zweck der Webanwendungsprojekte
Mit den Webanwendungsprojekten reagieren wir auf Kundenfeedback. Einige Entwickler halten das Migrieren von Visual Studio .NET 2003-Anwendungen zum neuen Websitemodell in Visual Studio 2005 insbesondere deshalb für unpraktisch, weil bei der Vorkompilierung (Veröffentlichung) einer Visual Studio 2005-Website mehrere Assemblys erstellt werden.
Der neue Projekttyp für Webanwendungen ermöglicht außerdem einige Szenarios, in denen sich Visual Studio 2005-Webprojekte von denen früherer Versionen von Visual Studio unterscheiden. So verfügt das neue Modell beispielsweise über eine andere Semantik für Webunterprojekte, bei denen es sich nicht um eine ASP.NET- oder IIS-Anwendung handelt, sondern die generierte Assembly im Ordner Bin der übergeordneten Anwendung abgelegt wird.
Der neue Projekttyp bietet außerdem ein für Entwickler vertrautes Modell, die die Strukturierung von Webprojekten in Visual Studio .NET 2003 weiter beibehalten wollen (z. B. die Verwendung einer Projektdatei).
Der neue Projekttyp für Webanwendungen ersetzt nicht etwa den in Visual Studio 2005 eingeführten Websiteprojekttyp, der viele neue Features und eine zusätzliche Flexibilität in der Verwaltung von Webanwendungen bietet. Stattdessen handelt es sich um einen alternativen Projekttyp, der entsprechend den Anforderungen oder dem bevorzugten Entwicklungsworkflow ausgewählt werden kann. Einigen Entwicklern wird das Visual Studio 2005-Standardwebsite-Projektmodell vertraut und benutzerfreundlich erscheinen. Andere Entwickler bevorzugen ein Modell, bei dem die Projektressourcen explizit definiert werden (statt implizit durch das bloße Vorhandensein in einem Ordner), und bei dem sie über eine genauere Steuerung des Projekts verfügen. Daher werden diese Entwickler das neue Webanwendungsprojekt-Modell verwenden. Statt die Entwickler zu zwingen, nur ein Projektmodell zu verwenden, unterstützen wir beide Projektmodelle und ermöglichen den Entwicklern die Auswahl des für sie geeigneten Webprojektmodells.
Hinweis: Webanwendungsprojekte können in Visual Web Developer Express Edition nicht verwendet werden.
In diesem Artikel
In diesem Artikel werden Webanwendungsprojekte beschrieben. Außerdem erhalten Sie Informationen zur Wahl zwischen einem Webanwendungsprojekt- und einem Websiteprojekt-Modell in Visual Studio 2005. Zudem werden folgende verbreitete Szenarios vorgestellt:
Erstellen eines neuen Webanwendungsprojekts in Visual Studio 2005.
Migrieren eines vorhandenen Visual Studio .NET 2003-Projekts zu einem Visual Studio 2005-Webanwendungsprojekt.
Im Anhang werden zusätzlich bekannte Probleme im Zusammenhang mit Webanwendungsprojekten aufgeführt.
Installieren von Webanwendungsprojekten
Um Visual Studio 2005 Webanwendungsprojekte hinzufügen zu können, muss sowohl ein Update als auch ein Add-In von Visual Studio 2005 installiert werden. Bei diesen beiden Installationen werden folgende Arbeiten durchgeführt:
Beim Update werden an Visual Studio 2005 notwendige Änderungen vorgenommen, damit der Assistent für die Konvertierung von Webprojekten und der Designer problemlos für Webanwendungsprojekte verwendet werden können. Das Update kann von der Microsoft Download Center-Seite Microsoft Visual Studio 2005 - Update to Support Web Application Projects (in englischer Sprache) heruntergeladen werden.
Mithilfe des Add-Ins sind die neuen Webanwendungsprojekte in Visual Studio 2005 verfügbar. Es kann unter Visual Studio 2005 Web Application Projects (in englischer Sprache) vom ASP.NET Developer Center heruntergeladen werden.
Im Dezember 2005 und im Februar 2006 wurden frühe Versionen (V1- und V2-Previews) der Webanwendungsprojekte veröffentlicht. Die aktuellste Version ist um die Unterstützung von Codegenerierung zur Einbindung von Serversteuerelementen und um das direkte Konvertieren von Visual Studio .NET 2003-Projekten in Webanwendungsprojekte für Visual Studio 2005 erweitert worden.
Vergleich von Websiteprojekten und Webanwendungsprojekten
Das neue Webanwendungsprojekt-Modell verfügt über dieselbe Semantik wie Visual Studio .NET 2003-Webprojekte. Dazu gehört eine auf Projektdateien basierte Struktur und ein Buildmodell, bei dem der gesamte Code eines Projekts in eine einzige Assembly kompiliert wird. Für den neuen Projekttyp stehen jedoch auch alle neuen Features von Visual Studio 2005 (Refactoring, Klassendiagramme, Testentwicklung, generische Typen, usw.) und von ASP.NET 2.0 (Masterseiten, Datensteuerelemente, Mitgliedschaft und Anmeldung, Rollenverwaltung, Webparts, Personalisierung, Sitenavigation, Designs usw.) zur Verfügung.
Durch das Webanwendungsprojekt-Modell in Visual Studio 2005 entfallen außerdem die beiden Anforderungen von Visual Studio .NET 2003:
Verwendung von FrontPage-Servererweiterungen (FPSE). FPSE sind nicht mehr erforderlich, werden aber für Sites weiter unterstützt, für die sie bereits verwendet werden.
Verwenden einer lokalen Kopie von IIS. Der neue Projekttyp unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server.
In den beiden folgenden Tabellen werden die Unterschiede zwischen Webanwendungsprojekten und Websiteprojekten beschrieben. In der ersten Tabelle werden verschiedene Szenarios und Aufgaben hervorgehoben, anhand derer empfohlen wird, welches Modell sich für die jeweilige Aufgabe eignet. In der zweiten Tabelle werden die Unterschiede im Verhalten der beiden Modelle ausführlicher beschrieben. Verwenden Sie die Tabellen zur Auswahl des geeigneten Modells.
In der folgenden Tabelle werden Webprojektoptionen oder Aufgaben aufgeführt und angegeben, welches Projektmodell diese Optionen besser implementiert.
Option oder Aufgabe |
Webanwendungsprojekte |
Websiteprojekte |
Große Visual Studio .NET 2003-Projekte müssen migriert werden |
X |
- |
Einzelseitencode-Modell soll Codebehind-Modell vorgezogen werden |
- |
X |
Dynamische Kompilierung und das Arbeiten an Seiten, ohne für jede Seitenanzeige die gesamte Site zu erstellen, soll bevorzugt werden (d. h. die Datei wird gespeichert, und die Seite anschließend im Browser lediglich aktualisiert). |
- |
X |
Die Namen der Ausgabeassemblys müssen gesteuert werden |
X |
- |
Für jede Seite muss eine Assembly generiert werden |
- |
X |
Für das Verweisen auf Seiten- und Benutzersteuerelement-Klassen sind eigenständige Klassen erforderlich |
X |
- |
Eine Webanwendung muss unter Verwendung mehrerer Webprojekte erstellt werden |
X |
- |
Bei der Kompilierung müssen vor und nach dem Build Schritte hinzugefügt werden |
X |
- |
Alle Verzeichnisse sollen als Webprojekt geöffnet und bearbeitet werden, ohne eine Projektdatei zu erstellen |
- |
X |
Anhand der folgenden Tabelle, die einige der Hauptunterschiede zwischen Webanwendungs- und Websiteprojekten beschreibt, können Sie einen Projekttyp auswählen.
Szenario |
Webanwendungsprojekt |
Websiteprojekt |
Projektdefinition |
Ähnlich wie Visual Studio .NET 2003. Zum Projekt gehören ausschließlich Dateien, auf die in der Projektdatei verwiesen wird. Ausschließlich diese Dateien werden im Projektmappen-Explorer angezeigt und beim Erstellen kompiliert. Da eine Projektdatei vorhanden ist, werden einige Szenarios erleichtert: Eine ASP.NET-Anwendung kann in mehrere Visual Studio-Projekte aufgeteilt werden. Dateien können einfach aus dem Projekt und der Quellcodeverwaltung ausgeschlossen werden. |
Die Inhalte des Projekts werden bei Websiteprojekten anhand der Ordnerstruktur definiert. Es ist keine Projektdatei vorhanden. Alle Dateien im Ordner gehören zum Projekt. Dieser Projekttyp empfiehlt sich, wenn eine Ordnerstruktur einer ASP.NET-Anwendung entspricht, die in Visual Studio bearbeitet werden soll, ohne explizit eine Projektdatei zu erstellen. |
Kompilierung und Buildausgabe |
Das Kompilierungsmodell von Webanwendungsprojekten ist dem in Visual Studio .NET 2003 sehr ähnlich. Alle Codebehind- und eigenständigen Klassendateien im Projekt werden in eine einzige Assembly kompiliert, die sich im Ordner Bin befindet. Da es sich um eine einzige Assembly handelt, können Attribute wie der Assemblyname und die Version sowie der Speicherort der Ausgabeassembly festgelegt werden. Bestimmte andere Anwendungsszenarios, wie das Model-View-Controller-Pattern (MVC), sind praktischer, da sie im Projekt zulassen, dass eigenständige Klassen auf Seiten und Benutzersteuerelement-Klassen verweisen. |
Mithilfe des Befehls Build werden Websiteprojekte lediglich zu Testzwecken kompiliert. Um Websiteprojekte auszuführen, werden Quelldateien zur Verfügung gestellt. Außerdem wird die dynamische ASP.NET-Kompilierung verwendet, um in der Anwendung Seiten und Klassen zu kompilieren. Die Site kann auch aus Leistungsgründen vorkompiliert werden. Hierbei wird dieselbe Kompilierungssemantik wie bei der dynamischen ASP.NET-Kompilierung verwendet. Das dynamische Kompilierungssystem von ASP.NET verfügt über zwei Modi: den Batchmodus (Standard) und den festen Namensmodus. Im Batchmodus werden beim Vorkompilieren der Site mehrere Assemblys (in der Regel eine je Ordner) erstellt. Im festen Modus wird für jede Seite oder jedes Benutzersteuerelement der Website eine Assembly erstellt. |
Iterative Entwicklung |
Um Seiten auszuführen und zu debuggen, muss das gesamte Webprojekt erstellt werden. Das Erstellen des vollständigen Webanwendungsprojekts erfolgt in der Regel sehr schnell, da Visual Studio ein inkrementelles Buildmodell enthält, bei dem lediglich die geänderten Seiten erstellt werden. |
In Visual Studio 2005 können Sie beim Ausführen der Site die folgenden Buildoptionen konfigurieren: Erstellen der Site, eine einzelne Seite oder keine. Im letztgenannten Fall wird in Visual Studio beim Ausführen der Website lediglich der Browser gestartet und die aktuelle oder die Startseite übergeben. Die Anforderung löst die dynamische ASP.NET-Kompilierung aus. Da Seiten je nach Bedarf in verschiedene Assemblys dynamisch kompiliert werden, muss nicht das gesamte Projekt erfolgreich kompiliert werden, um eine Seite ausführen oder debuggen zu können. In der Standardeinstellung werden Websiteprojekte in Visual Studio beim Ausführen oder Debuggen einer Seite stets kompiliert. Dadurch sollen Kompilierungsfehler auf der gesamten Site erkannt werden. Das Erstellen einer vollständigen Site kann jedoch den iterativen Entwicklungsprozess deutlich verlangsamen. Daher wird empfohlen, die Option zum Erstellen der Site dahingehend zu ändern, dass beim Ausführen oder Debuggen lediglich die aktuelle Seite kompiliert wird. |
Bereitstellung |
Da alle Klassendateien in eine einzige Assembly kompiliert werden, muss (neben den ASPX- und ASCX-Dateien und weiteren Dateien mit statischem Inhalt) lediglich diese Assembly bereitgestellt werden. In diesem Modell werden ASPX-Dateien erst bei der Ausführung im Browser kompiliert. Bei der Verwendung in Web-Bereitstellungsprojekten (einem Add-In-Download für Visual Studio 2005) können die ASPX-Dateien jedoch auch für die Bereitstellung kompiliert und in eine einzelne Assembly eingefügt werden. Bei jeder Bereitstellung der in diesem Modell erstellten einzelnen Assembly wird der Code aller Seiten im Projekt ersetzt. |
Sowohl ASPX- als auch Codebehind-Dateien können in Visual Studio mithilfe des Befehls Publish Website (Website veröffentlichen) in Assemblys kompiliert werden. (Beachten Sie, dass der Befehl Build keinen bereitstellbaren Satz von Assemblys erstellt.) Die Option zur aktualisierbaren Veröffentlichung unterstützt lediglich das Kompilieren von Codebehind-Dateien. ASPX-Dateien werden nicht für die Bereitstellung geändert. Im Standardmodus der Vorkompilierung werden im Ordner Bin mehrere Assemblys erstellt (in der Regel eine je Ordner). Mit der Option für feste Namen wird eine Assembly je Seite oder Benutzerelement erstellt. Sie kann verwendet werden, um bereitstellbare Versionen einzelner Seiten zu erstellen. Diese Option führt jedoch zu einer größeren Anzahl an Assemblys und kann somit zu einer höheren Speicherauslastung führen. |
Aktualisieren von Visual Studio .NET 2003 |
Da das Webanwendungsprojekt-Modell mit dem in Visual Studio .NET 2003 identisch ist, erfolgt die Aktualisierung recht einfach, und die Anwendung muss nicht neu strukturiert werden. |
Die Kompilierungsoption für Websiteprojekte unterscheidet sich deutlich von der in Visual Studio .NET 2003. Für das Konvertieren vorhandener Visual Studio .NET 2003-Webprojekte in Websiteprojekte steht ein Assistent zur Verfügung. Bei recht komplexen Visual Studio .NET 2003-Projekten ist eine manuelle Überarbeitung im Anschluss an die Konvertierung in der Regel erforderlich. In den meisten Szenarios empfiehlt sich das Aktualisieren vorhandener Visual Studio .NET 2003-Projekte in Visual Studio 2005-Webanwendungsprojekte. |
Szenario 1: Erstellen eines neuen Webanwendungsprojekts
Dieser Abschnitt führt Sie schrittweise durch das Erstellen eines neuen Webanwendungsprojekts. Außerdem wird untersucht, wie Seitencode in einem Visual Studio 2005-Webanwendungsprojekt behandelt wird.
Hinweis: Webanwendungsprojekte können in Visual Web Developer Express Edition nicht verwendet werden.
Sämtliche dargestellten Beispiele in diesem Artikel wurden in C# verfasst. Die Schritte für das Arbeiten mit Visual Basic sind jedoch absolut analog, lediglich die Dateinamen und der jeweilige Code weichen ein wenig ab. Die Inhalte dieses Artikels sind also für VB.NET-Entwickler trotz des aktiven Gebrauchs von C# keinesfalls weniger interessant.
Schritt 1: Erstellen eines neuen Projekts
Zunächst muss ein neues Webanwendungsprojekt erstellt werden. Klicken Sie in Visual Studio im Menü Datei auf Neues Projekt, um das Dialogfeld Neues Projekt anzuzeigen.
Hinweis: Zum Erstellen eines Webanwendungsprojekts wählen Sie (anders als beim Erstellen eines Websiteprojekts) nicht den Befehl Neue Website aus. Stattdessen wird der Befehl Neues Projekt verwendet.
Öffnen Sie unter Projekttypen den Knoten Visual C# oder Visual Basic , und klicken Sie anschließend unter Von Visual Studio installierte Vorlagen auf ASP.NET-Webanwendung:
.gif "Abbildung1")
Abbildung 1: Erstellen eines neuen Webanwendungsprojekts
Geben Sie für das Projekt einen Namen und einen Speicherort an. Wenn Sie auf OK klicken, wird in Visual Studio ein neues Webprojekt erstellt und geöffnet, das eine einzelne Seite mit dem Namen Default.aspx, die Datei AssemblyInfo.cs sowie die Datei Web.config enthält:
.gif "Abblidung2")
Abbildung 2: Neues Webanwendungsprojekt
Die Liste der Projektdateien, Verweise, Kompilierungsinformationen und weiterer Metadaten wird in der Projektdatei gespeichert, die an dem Ort abgelegt wird, der im Dialogfeld Neues Projekt angegeben wurde.
Der Seite Default.aspx sind zwei Klassendateien zugeordnet. Die Datei Default.cs enthält die Seitenklasse, die den Code und die Ereignishandler beinhaltet. Die Datei Default.aspx.designer.cs ist eine neue Datei, die in Webanwendungsprojekten den von Visual Studio für die Seite generierten und gewarteten Code enthält. Beide Dateien beinhalten eine partielle Klasse. Bei der Kompilierung werden die beiden Dateien zu einer einzelnen Codebehind-Klasse kombiniert.
Schritt 2: Öffnen und Bearbeiten der Seite
Öffnen Sie die Datei Default.aspx, und fügen Sie folgendes Markup ein, das verschiedene ASP.NET-Serversteuerelemente definiert:
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication3._Default" %>
<html>
<head runat="server">
<title>My Visual Studio 2005 Web Application Project Test</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<h1>My Visual Studio 2005 Web Application Project Test</h1>
<h3>Pick a date: </h3>
<asp:Calendar ID="Calendar1" runat="server"
BorderColor="#999999" DayNameFormat="Shortest"
Font-Names="Verdana">
<SelectedDayStyle BackColor="#666666"
Font-Bold="True" ForeColor="White" />
<TodayDayStyle BackColor="#CCCCCC" ForeColor="Black" />
<SelectorStyle BackColor="#CCCCCC" />
<WeekendDayStyle BackColor="#FFFFCC" />
<OtherMonthDayStyle ForeColor="#808080" />
<NextPrevStyle VerticalAlign="Bottom" />
<DayHeaderStyle BackColor="#CCCCCC" Font-Bold="True"
Font-Size="7pt" />
<TitleStyle BackColor="#999999" BorderColor="Black"
Font-Bold="True" />
</asp:Calendar>
<br />
<div>
<asp:Label ID="Label1" runat="server" Text="Label"/>
</div>
</div>
</form>
</body>
</html>
Die Datei Default.aspx.designer.cs wird in Webanwendungsprojekten automatisch aktualisiert, wenn in der Datei Default.aspx Steuerelemente hinzugefügt oder entfernt werden. Der folgende Ausschnitt zeigt die Datei Default.aspx.designer.cs nach dem Hinzufügen des Markups:
namespace WebApplication3
{
public partial class _Default
{
protected System.Web.UI.HtmlControls.HtmlForm form1;
protected System.Web.UI.WebControls.Calendar Calendar1;
protected System.Web.UI.WebControls.Label Label1;
}
}
Die Datei Default.aspx.designer.cs enthält eine Steuerelementdeklaration für jedes Serversteuerelement in der ASPX- (oder ASCX-) -Datei. In der Standardeinstellung sind die Steuerelemente als protected deklariert. Sie können die .designer.cs-Datei öffnen und einen Accessor des Felds in public ändern, wenn von außen auf die Variable Ihrer Klasse zugegriffen werden soll.
Hinweis: Es wird nicht empfohlen, den Zugriff auf Steuerelementdeklarationen auf public zu setzen. Es ist sinnvoller, eine Eigenschaft zum Ändern des Zugriffs auf eine Serversteuerelement-Variable zu verwenden. Das Bearbeiten des Zugriffsmodifizierers für Servervariablen in der Designerdatei wird jedoch zur Abwärtskompatibilität mit Visual Studio .NET 2003-Webprojekten unterstützt, bei denen diese Codierungstechnik verwendet wurde.
In Webanwendungsprojekten wurde die Codegenerierung für Serversteuerelemente anhand der Erfahrung mit Visual Studio .NET 2003 auf zwei wichtige Arten verbessert:
Die Seite muss nicht mehr in die Entwurfansicht verschoben werden, um die Steuerelementdeklarationen zu ändern. Im Designer werden sowohl die Entwurfs- als auch die Quellansicht überwacht und die Deklarationen entsprechend aktualisiert.
Die Steuerelementdeklarationen der Basisklasse einer Seite werden berücksichtigt und nicht in der Codebehind-Klasse einer Seite dupliziert.
Da die Datei .designer.cs automatisch mit den Steuerelementdeklarationen aktualisiert wird, können Sie direkt zur Codebehind-Klassendatei Default.aspx.cs wechseln und (wie im folgenden Beispiel) beliebige Steuerelemente der Seite programmieren:
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
namespace WebApplication3 {
public partial class _Default : System.Web.UI.Page {
protected void Page_Load(object sender, EventArgs e) {
Label1.Text = "Current date: " + Calendar1.SelectedDate;
}
}
}
Schritt 3: Erstellen und Ausführen des Projekts
Führen Sie das Projekt im Debugmodus aus, indem Sie auf F5 drücken oder im Menü Debuggen auf Ausführen klicken. In der Standardeinstellung verwenden Webanwendungsprojekte den integrierten ASP.NET Development Server und als Stammsite einen zufälligen Port (so kann die URL der Seite z. B. https://localhost:12345/ lauten):
.gif "Abbildung3")
Abbildung 3: Ausführen eines Webanwendungsprojekts
Beim Erstellen von Webanwendungsprojekten werden alle Codebehind- und eigenständigen Klassendateien in eine einzige Assembly kompiliert, die sich im Ordner Bin des Projekts befindet.
Der Ausgabespeicherort kann gegebenenfalls geändert werden, etwa um das Projekt in einem übergeordneten Anwendungsverzeichnis zu erstellen. In der Regel wird der Build- Ausgabepfad eingerichtet, wenn mehrere Unterprojekte in Unterordnern einer einzelnen ASP.NET-Anwendung vorhanden sind. Wählen Sie die Eigenschaften des Projekts aus, um den Build-Ausgabepfad wie im folgenden Screenshot einzurichten:
.gif "Abbildung4")
Abbildung 4: Einrichten des Ausgabebuildspeicherorts
Nach dem Erstellen des Projekts können die Ergebnisse untersucht werden. Klicken Sie im Projektmappen-Explorer auf Alle Dateien anzeigen:
.gif "Abbildung5")
Abbildung 5: Ergebnisse des Erstellens eines Webanwendungsprojekts
Diese Vorgehensweise ist identisch mit der für ASP.NET-Webprojekte in Visual Studio .NET 2003.
Festlegen von Build- und Bereitstellungseigenschaften für Webanwendungsprojekte
Für ASP.NET-Webanwendungsprojekte werden dieselben Konfigurationseinstellungen und Verhaltensweisen wie für Visual Studio 2005-Klassenbibliotheksprojekte verwendet. Auf diese Konfigurationseinstellungen kann zugegriffen werden, indem Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen klicken und Eigenschaften auswählen. Dadurch wird der Editor für die Projekteigenschaften angezeigt. Der Editor kann verwendet werden, um verschiedene Eigenschaften zu ändern, z. B. den Namen der generierten Assembly, die Kompilierungseinstellungen des Projekts, die Verweise, die Werte von Ressourcenzeichenfolgen und die Einstellungen zum Signieren des Codes:
.gif "Abbildung6")
Abbildung 6: Ändern der Eigenschaften eines Webanwendungsprojekts
In ASP.NET-Webanwendungsprojekten wird der Liste der Projekteigenschaften die Registerkarte Web hinzugefügt. Auf dieser Registerkarte kann konfiguriert werden, wie ein Webprojekt ausgeführt und debuggt wird. In der Standardeinstellung sind ASP.NET-Webanwendungsprojekte so konfiguriert, dass sie unter Verwendung des integrierten ASP.NET Development Server auf einem zufälligen HTTP-Port des Computers gestartet und ausgeführt werden. Die folgenden Screenshots zeigen, dass hier der ASP.NET Development Server verwendet wird: Das Taskleistensymbol und eine Seite im Browser, deren URL im Feld Adresse angezeigt wird, weisen darauf hin.
.gif "Abbildung7")
Abbildung 7: Taskleistensymbol für ASP.NET Development Server
.gif "Abbildung8")
Abbildung 8: Ausführen eines Webanwendungsprojekts unter Verwendung des ASP.NET Development Servers
Die Portnummer kann geändert werden, wenn der ausgewählte Port bereits verwendet wird oder Sie das Webprojekt unter Verwendung eines bestimmten Ports ausführen möchten (vgl. Abbildung 9).
.gif "Abbildung9")
Abbildung 9: Ändern des vom ASP.NET Development Server verwendeten Ports
Die Ausführung und das Debuggen von Webanwendungen kann in Visual Studio auch mithilfe von IIS erfolgen. Um IIS zu verwenden, wählen Sie IIS-Webserver verwenden aus, und geben Sie den URL der Webanwendung ein:
.gif "Abbildung10")
Abbildung 10: Konfigurieren eines Webanwendungsprojekts für die Verwendung von IIS
Hinweis: ASP.NET-Webanwendungsprojekte erstellen nicht automatisch einen virtuellen IIS-Stamm oder eine Anwendung. Um das virtuelle Verzeichnis und die Anwendung in IIS zu erstellen, klicken Sie neben dem Feld URL auf die Schaltfläche Virtuelles Verzeichnis erstellen.
Beim Ausführen wird das Projekt in Visual Studio in eine einzelne Assembly kompiliert. Dies entspricht der Build-Semantik von Visual Studio .NET 2003-Webprojekten. Beim Ausführen der Anwendung wird dem Webserverprozess in Visual Studio ein Debugger angehängt.
Alle Projekteinstellungen werden in einer standardisierten MSBuild-Projektdatei gespeichert.
Anpassen der Bereitstellungsoptionen für Webanwendungsprojekte
Im Anschluss an das Erstellen eines Webanwendungsprojekts kann optional ein Visual Studio 2005-Web-Bereitstellungsprojekt verwendet werden, um die Bereitstellungsoptionen des Webanwendungsprojekts festzulegen.
Hinweis: Web-Bereitstellungsprojekte sind als Visual Studio 2005-Add-Ins verfügbar. Das Add-In kann von der Seite Visual Studio 2005 Web Deployment Projects (in englischer Sprache) im ASP.NET Developer Center heruntergeladen werden.
In Webanwendungsprojekten wird der gesamte Code in eine einzelne Assembly kompiliert, sodass kein Visual Studio 2005-Web-Bereitstellungsprojekt zum Kombinieren der Assemblys erforderlich ist. Web-Bereitstellungsprojekte stellen jedoch eine zusätzliche Unterstützung beim Vorkompilieren des ASPX-Inhalts eines Projekts dar. Dies gilt auch für Änderungen der veröffentlichten Konfiguration nach dem Erstellen. Unter Verwendung des aktuellsten Build des Web-Bereitstellungsprojekt-Add-Ins können Sie diese Funktionen sowohl Visual Studio 2005-Websiteprojekten als auch Visual Studio 2005-Webanwendungsprojekten hinzufügen.
Szenario 2: Migrieren eines Visual Studio .NET 2003-Webprojekts zu einem Webanwendungsprojekt
Dieser Abschnitt führt Sie schrittweise durch das Konvertieren eines vorhandenen Visual Studio .NET 2003-Webprojekts in ein Visual Studio 2005-Webanwendungsprojekt. Das Webanwendungsprojekt-Modell verwendet denselben konzeptionellen Ansatz wie ein Webprojekt in Visual Studio .NET 2003. Dies schließt eine Projektdatei zum Ein- und Ausschließen von Dateien, das Kompilieren in eine einzelne Assembly, usw. mit ein. Im Allgemeinen erfordern Webanwendungsprojekte nach der Konvertierung keine Änderungen der Architektur.
Wie im vorherigen Abschnitt wird auch hier davon ausgegangen, dass Sie in C# arbeiten. Erneut gilt: Die Schritte für das Arbeiten mit Visual Basic sind sehr ähnlich, lediglich die Dateinamen und der Code weichen etwas ab.
Schritt 1: Installieren der Vorabversion für Visual Studio 2005-Webanwendungsprojekte
Stellen Sie sicher, dass die Webanwendungsprojekte entsprechend der Schritte im Abschnitt Installieren von Webanwendungsprojekten dieses Dokuments installiert wurden.
Schritt 2: Sichern der Visual Studio .NET 2003-Projekte
Ihre Visual Studio .NET 2003-Webprojekte und -Lösungen müssen vor dem Migrationsversuch unbedingt gesichert werden. Die folgenden Schritte wurden mit der Vorabversion der Webanwendungsprojekte getestet. Sollten dennoch Probleme auftreten, müssen Sie möglicherweise die Visual Studio .NET 2003-Lösung wiederherstellen.
Schritt 3: Öffnen und Überprüfen des Visual Studio .NET 2003-Webprojekts
Öffnen, kompilieren und führen Sie Ihre vorhandene Visual Studio .NET 2003-Lösung vor dem Migrieren aus. Nehmen Sie sich vor dem Migrieren etwas Zeit, um sicherzustellen, dass keine Probleme auftreten. Dies kann Ihnen später einigen Ärger ersparen, insbesondere wenn es sich z. B. um Verzeichnisänderungen in letzter Minute oder Ähnliches handelt.
Schritt 4: Migrieren der Lösung zu Visual Studio 2005
Schließen Sie die Lösung in Visual Studio .NET 2003, und starten Sie anschließend Visual Studio 2005. Klicken Sie im Menü Datei auf Datei öffnen, und navigieren Sie anschließend zur SLN-Datei der zu migrierenden Lösung. Dadurch wird der Visual Studio 2005-Assistent für die Konvertierung gestartet:
.gif "Abbildung11")
Abbildung 11: Visual Studio 2005-Assistent für die Konvertierung
Klicken Sie auf Weiter, um im Assistenten fortzufahren, und akzeptieren Sie alle Standardeinstellungen. Die Lösung und die enthaltenen Projektdateien werden in Visual Studio 2005 zur Verwendung des MSBuild-Formats konvertiert (dem neuen Projektdateiformat in Visual Studio 2005).
Als Teil der Migration wird in Visual Studio 2005 eine XML-basierte Protokolldatei generiert, die eine Zusammenfassung des Konvertierungsvorgangs enthält und auf alle bei der Migration aufgetretenen Probleme hinweist. In der Standardeinstellung wird die Konvertierungsprotokolldatei im selben Verzeichnis wie die SLN-Datei gespeichert. Wenn beim Kompilieren des Projekts nachträglich Fehler auftreten, sollten Sie gegebenenfalls die Konvertierungsprotokolldatei zu Rate ziehen.
Schritt 5: Überprüfen in Visual Studio 2005
Nachdem die Lösung und die Projektdateien in das Visual Studio 2005-Format aktualisiert wurden, muss überprüft werden, ob Ihre Anwendung ohne Fehler erstellt und wie erwartet ausgeführt wird. An dieser Stelle treten häufig folgende Fehler- oder Warnungstypen auf:
Konflikte mit in .NET Framework Version 2.0 eingeführten Namen.
Warnungen zur Verwendung veralteter Mitglieder.
Um Namenskonflikte zu beheben, können zur Vermeidung einer Mehrdeutigkeit entweder vorhandene Namen mit einem Namespace vollqualifiziert, oder die Mitglieder so umbenannt werden, dass keine Konflikte auftreten.
Die angezeigten Warnungen zur Verwendung veralteter Mitglieder enthalten in der Regel Vorschläge zur Verwendung anderer APIs. In diesen Fällen können Sie damit fortfahren, die veralteten Mitglieder in der 2.0 Version des .NET Framework zu verwenden. Die Mitglieder werden jedoch mit der nächsten Hauptversion von .NET Framework entfernt. Daher ist es sinnvoll, diese durch die vorgeschlagenen Alternativen zu ersetzen.
Schließen Sie den Browser.
Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Startseite der Anwendung, und klicken Sie auf Als Startseite festlegen, um sicherzustellen, dass bei der Ausführung der Anwendung die richtige Seite aufgerufen wird.
Führen Sie die Anwendung erneut aus.
Beim Ausführen einer Webanwendung wird möglicherweise der Fehler "Auflistung in Verzeichnis verweigert" angezeigt. Diese Meldung deutet auf ein virtuelles Verzeichnis hin, das eine Auflistung der Inhalte nicht gestattet. Gehen Sie folgendermaßen vor, wenn diese Fehlermeldung angezeigt wird:
Schritt 6: Konvertieren von Codebehind-Klassen in partielle Klassen
Wie erwähnt verwenden Webanwendungsprojekte in Visual Studio 2005 zum Speichern von durch Designer generiertem Code partielle Klassen. Diese Klassen werden nicht in der Codebehind-Datei, sondern in einer separaten Datei gespeichert. In der Standardeinstellung erstellt der Visual Studio 2005-Assistent für die Konvertierung von Webprojekten für Webseiten (ASPX-Dateien) oder Benutzersteuerelemente keine *.designer.cs-Datei. Stattdessen entspricht der Code in Darstellung und Funktion dem in Visual Studio .NET 2003.
Hinweis: Der Assistent nimmt bei der Migration nur minimale Änderungen an den Codedateien vor, um eine nahtlose Konvertierung in Visual Studio 2005-Webanwendungsprojekte sicherzustellen.
Sie können den Code in diesem Format beibehalten. Hierzu müssen Sie die Steuerelementfeld-Deklarationen in den Codebehind-Dateien manuell aktualisieren. Alle anderen Funktionen werden jedoch problemlos in Visual Studio 2005 übernommen.
Im Editor besteht die Möglichkeit, die Felddeklarationen des generierten Codes beizubehalten. Um diesen Vorteil zu nutzen, sollten Sie Ihre Seiten und Steuerelemente zur Verwendung des in ASP.NET 2.0 eingeführten Modells für partielle Klassen aktualisieren. Partielle Klassen vereinfachen die Organisation des generierten und des benutzerdefinierten Codes in den Codebehind-Dateien. Weitere Informationen zu .designer.cs-Dateien finden Sie weiter oben unter Szenario 1: Erstellen eines neuen Webanwendungsprojekts.
Um Ihren Code zur Verwendung des partiellen Klassenmodells zu migrieren, sollten Sie zunächst sicherstellen, dass der Code ohne Fehler kompiliert wird. Klicken Sie anschließend im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen, und klicken Sie auf In Webanwendung konvertieren. Dieser Befehl durchläuft alle Seiten und Benutzersteuerelemente des Projekts, verschiebt alle Steuerelementdeklarationen in eine .designer.cs-Datei und fügt dem Serversteuerlement-Markup in den ASPX- und ASCX-Dateien Ereignishandlerdeklarationen hinzu.
Hinweis: Sie können den Befehl In Webanwendung konvertieren auch für einzelne Seiten verwenden. Sie können ihn beispielsweise zunächst für einige wenige Seiten anwenden, um die an den Seiten vorgenommenen Änderungen genau zu beobachten, bevor Sie diese für die gesamte Anwendung vornehmen.
.gif "Abbildung12")
Abbildung 12: Konvertieren einer einzelnen Seite in das Format Webanwendungsprojekt
Wechseln Sie im Anschluss an diesen Vorgang zum Fenster Aufgabenliste, um zu überprüfen, ob Berichte über aufgetretene Konvertierungsfehler vorliegen. Wenn in der Aufgabenliste Fehler angezeigt werden, klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die entsprechende Seite, und wählen Sie Code anzeigen und Codegenerierte Datei anzeigen aus, um den Code zu untersuchen und Fehler zu beheben. Beachten Sie, dass im Fenster Aufgabenliste angezeigte Fehler und Warnungen in Visual Studio sitzungsübergreifend beibehalten werden. Nachdem die im Fenster aufgeführten Fehler behoben wurden, können die entsprechenden Elemente aus der Aufgabenliste gelöscht werden.
Hinweis: Der Befehl In Webanwendung konvertieren kann in Visual Studio nicht rückgängig gemacht werden. Um die Änderungen rückgängig zu machen, empfiehlt sich daher das Wiederherstellen aus einer Sicherung des Visual Studio .NET 2003-Projekts. Anschließend sollte die Visual Studio 2005-Migration wiederholt werden (siehe Schritt 4).
Kompilieren Sie Ihr Projekt erneut, um sicherzustellen, dass es ohne Fehler kompiliert wird. Wenn die Steuerelementdeklarationen in einer Codebehind-Klasse geändert wurden, kommt es häufig zu Fehlern, wenn der Assistent für die Konvertierung die Änderungen falsch verarbeitet.
Von nun an verwenden Seiten, die dem Webprojekt hinzugefügt werden, in der Standardeinstellung die Vorlage für partielle Klassen.
Schritt 7: Untersuchen und Beheben von XHTML-Kompatibilitätsproblemen
In der Standardeinstellung wird in Visual Studio 2005 ein XHTML-kompatibles Markup generiert und geprüft. Dies erleichtert das Erstellen von Webanwendungen, die den Standards entsprechen. Außerdem werden Probleme mit der browserspezifischen Wiedergabe minimiert. In Visual Studio .NET 2003 wurde kein XHTML-kompatibles Markup generiert, sodass bei den in Visual Studio .NET 2003 erstellten Seiten Überprüfungs- und Wiedergabeprobleme auftreten können.
Hinweis: Überprüfungsfehler haben reinen Informationscharakter und werden als Warnungen ausgewiesen. Sie führen nicht dazu, dass Seiten nicht ausgeführt werden.
Wenn keine Überprüfungsfehler angezeigt werden sollen, ändern Sie die HTML-Überprüfungseinstellung von XHTML Transitional in Internet Explorer 6.0 (der Standardeinstellung in Visual Studio .NET 2003). Klicken Sie im Menü Extras auf Optionen. Öffnen Sie im Dialogfeld Optionen die Knoten Texteditor, HTML und anschließend Überprüfung. Wählen Sie in der Liste Ziel Internet Explorer 6.0 aus, und deaktivieren Sie anschließend das Kontrollkästchen Fehler anzeigen. Beachten Sie, dass dadurch keine XHTML-Überprüfungsfehler behoben werden. Das Überprüfungsschema wird lediglich dahingehend geändert, dass es kompatibler mit dem in Visual Studio .NET 2003 generierten Markup ist, und dass Überprüfungswarnungen unterdrückt werden.
.gif "Abbildung13")
Abbildung 13: Konfigurieren der HTML-Überprüfung
Sie können der Web.config-Datei Ihres Projekt außerdem folgenden Abschnitt hinzufügen, der dazu führt, dass ASP.NET veraltetes (nicht XHTML-kompatibles) Markup für Serversteuerelemente wiedergibt:
<system.Web> <xhtmlConformance mode="Legacy" /> </system.Web>
Dadurch werden die kleinen Wiedergabeunterschiede von Seiten behoben, die mit ASP.NET 1.1 oder ASP.NET 2.0 angezeigt werden. Weitere Informationen finden Sie in der MSDN-Bibliothek unter ASP.NET and XHTML (in englischer Sprache).
Die Zukunft von Webanwendungsprojekten
Webanwendungsprojekte verfügen über ein Kompilierungs- und Buildmodell, das dem in Visual Studio .NET 2003 verwendeten sehr ähnlich ist. Entsprechend den jeweiligen Anforderungen erachten einige Benutzer die neue Option für Websiteprojekte in Visual Studio 2005 als geeigneter für ihre Anwendungen, während andere Benutzer die Webanwendungsprojekt-Option bevorzugen. Webanwendungsprojekte sind die beste Möglichkeit zum Aktualisieren von Visual Studio .NET 2003-Anwendungen in Visual Studio 2005. Daher werden Sie für dieses Szenario dringend empfohlen.
Folgende wichtige Punkte zur Zukunft von Visual Studio 2005-Webanwendungsprojekten sollen hier betont werden:
Zukünftig sollen sowohl das Visual Studio 2005-Websiteprojekt- als auch das Visual Studio 2005-Webanwendungsprojekt-Modell unterstützt werden. Sie können auswählen, welches Modell sich für Ihre Anforderungen besser eignet.
Das Webanwendungsprojekt-Modell wird in zukünftigen Versionen von Visual Studio integriert sein, und sowohl das Webanwendungsprojekt-Modell als auch das Websiteprojekt-Modell werden unterstützt.
Anhang A: Bekannte Probleme
Im Anhang werden bekannte Probleme im Zusammenhang mit Webanwendungsprojekten aufgeführt.
Problem 1: Datenszenarios
Es bestehen bekannte Probleme beim Verwenden von datengebundenen Steuerelementen und SQL Server 2005 Express mit der Webanwendungsprojekt-Version vom April 2006. Ein Liste aller Probleme und Umgehungen finden Sie im Whitepaper "Using Data-Bound Controls and SQL Server Express with Web Application Projects" im ASP.NET Developer Center auf der Seite Visual Studio 2005 Web Application Projects (in englischer Sprache).
Problem 2: Visual Basic-Inlinecode wird möglicherweise nicht ordnungsgemäß konvertiert
Beim Aktualisieren eines Visual Studio .NET 2003-Projekts in Visual Studio 2005 wird Visual Basic-Code von Einzeldatei-Webseiten (ASPX-Dateien) oder Benutzersteuerelementen (ASCX-Dateien) nicht für die Verwendung der neuen Visual Basic 2005-Syntax konvertiert. Dies kann beim Erstellen des konvertierten Webprojekts zu Fehlern beim Kompilieren führen. Diese Fehler müssen manuell behoben und die betroffenen Seiten neu kompiliert werden. Visual Basic-Code in Codebehind-Dateien wird konvertiert und sollte ordnungsgemäß kompiliert werden.
Problem 3: WSE und Webanwendungsprojekte
Web Services Enhancements (WSE) ist ein Add-In zu Visual Studio 2005, das die aktuellsten erweiterten Webdienstfunktionen bietet. Bei der Installation von Webanwendungsprojekten funktioniert der WSE-Konfigurationsbefehl im Kontextmenü des Projektmappen-Explorers nicht ordnungsgemäß. Führen Sie als Problemumgehung folgende Schritte aus, um stattdessen das eigenständige WSE 3.0-Konfigurationstool zu verwenden:
Starten Sie das Konfigurationstool. Klicken Sie dafür im Windows-Start-Menü auf Alle Programme, Microsoft WSE 3.0 und anschließend auf Konfigurationstool.
Klicken Sie im Menü Datei des Konfigurationstools auf Öffnen.
Wählen Sie die Datei Web.config des Projekts aus.
Problem 4: Konvertieren des Starter Kits für Vereinswebsites (Visual Basic)
Dieses Problem tritt nur beim Verwenden von Visual Basic auf. Beim Konvertieren der Visual Basic-Version des Starter Kits für Vereinswebsites in ein Webanwendungsprojekt wird in etwa folgender Laufzeitfehler angezeigt:
Server Error in '/' Application.
Compiler Error Message: BC30451: Name 'truncate' is not declared.
Source Error:
Line 129: <asp:Label ID="Label2" runat="server" Text='<%# truncate(CStr(Eval("description"))) %>' />
Source File: C:\vs05\328\test-club1\wap1\Default.aspx Line: 129
Um diesen Fehler zu beheben, müssen Sie einen zusätzlichen Namespace einbinden. Dies kann für einzelne Seiten oder das gesamte Projekt erfolgen. Führen Sie die folgenden Schritte aus (wobei der hier beispielhafte Projekt-Namespace "wap1" ist):
So fügen Sie einer einzelnen Seite einen Namespace hinzu
Öffnen Sie die Seite.
Fügen Sie unterhalb der letzten Direktive @ Register eine Direktive @ Import ein, die auf den zu verwendenden Namespace verweist (siehe Beispiel):
<%@ Register TagPrefix="Club" Namespace="wap1.Clubsite" Assembly="wap1"> <%@ Import Namespace="wap1" %>
So fügen Sie einem Projekt einen Namespace hinzu
Öffnen Sie die Datei Web.config.
Fügen Sie das Element <namespaces> hinzu, oder bearbeiten Sie es als untergeordnetes Element des Elements <pages> (siehe Beispiel):
<pages>
<namespaces>
<add namespace="wap1"/>
</namespaces>
</pages>
Problem 5: Konvertieren des Starter Kits für persönliche Websites (Visual Basic)
Dieses Problem tritt ausschließlich bei der Verwendung von Visual Basic auf. Beim Konvertieren der Visual Basic-Version des Starter Kits für persönliche Websites in ein Webanwendungsprojekt wird in etwa folgender Laufzeitfehler angezeigt:
Server Error in '/' Application The type specified in the TypeName property of ObjectDataSource 'ObjectDataSource1' could not be found
Um den Fehler zu beheben, müssen Sie der Eigenschaft TypeName den Projekt-Namespace hinzufügen. Führen Sie die folgenden Schritte aus (wobei der hier beispielhafte Projekt-Namespace "wap1" ist).
Öffnen Sie die Seite Member_List.aspx.
Ändern Sie den Typnamen in der Deklaration ObjectDataSource in eine vollqualifizierte Darstellung (siehe folgendes Beispiel):
<asp:ObjectDataSource TypeName="wap1.MemberDetails" >
Problem 6: Konvertieren eines Visual Studio 2005-Websiteprojekts in ein Webanwendungsprojekt
Dieses Dokument wird zu einem späteren Zeitpunkt aktualisiert, um die erforderlichen Schritte zum Konvertieren eines Visual Studio 2005-Websiteprojekts in ein Webanwendungsprojekt zu erläutern. Lesen Sie bis dahin den Eintrag Tutorial 8: Migrating from VS 2005 Web Site Projects to VS 2005 Web Application Projects im Blog von Scott Guthrie (in englischer Sprache).