Der Visual Web Developer (Die Web-Entwicklungsumgebung in Visual Studio
2005) bietet zwei verschiedene Modelle zur Entwicklung von ASP.NET
2.0-Webanwendungen:
Um dies zu verstehen, ist ein kurzer Rückblick notwendig.
Das Projektverwaltungssystem für ASP.NET-Webanwendungen in
Visual Studio .NET 2003 hatte seine Macken. Zum Erstellen eines Webprojekts in
Visual Studio .NET 2002/2003 brauchte man einen Webserver mit Front Page Server
Extensions (FPSE). Ganz abgesehen von den FPSE-eigenen Unreimtheiten hatten
Webentwickler immer dann Schwierigkeiten, wenn andere Personen (z.B.
Webdesigner) gleichzeitig mit Werkzeugen an dem Projekt arbeiteten, die nicht
auf FPSE basieren. Die Geschwindigkeit beim Öffnen von Projekten war zudem
gering, was besonders Benutzern mit mehreren tausend Webseiten sehr schmerzlich
auffiel.
Auch innerhalb von Visual Studio war nicht alles zum
Besten. Oft kam es zu Inkonsistenzen zwischen der ASPX-Seite und dem vom
Designer generierten Code. Zudem verwendete die Entwicklungsumgebung ein völlig
anderes Übersetzungssystem als das ASP.NET Page Framework selbst, was dazu
führte, dass viele Fehler (z.B. falsche Konfigurationseinträge) nicht von der
Entwicklungsumgebung, sondern erst von der Laufzeitumgebung bemerkt wurden.
Mit
dem Visual Web Developer 2005 wollte Microsoft das Rad neu erfinden und erfand das
neue
Websitemodell, das abseits des eigentlichen
Visual Studio-Projektsystems funktioniert. Doch nicht alle Anwender kamen mit
der neuen Philosophie zurecht. Genau einen Monat nach dem offiziellen
Erscheinungstermin von Visual Studio 2005
kündigte der Chef des Redmonder ASP.NET-Teams, Scott Guthrie , an, dass
das alte Projektsystem in veränderter Form als eine Option unter dem Namen
Webanwendungsmodell
zurückkehren wird. Ab Visual Studio 2008 sind beide Modell ethalten.
|
Websitemodell
|
Webanwendungsmodell
|
Produktstatus
|
Enthalten in
Visual Studio ab Version 2005
|
Zusatz für Visual
Studio 2005, enthalten ab Visual Studio 2008
|
Anlegen
eines Projekts
|
Datei/Neu/Website "ASP.NET
Website"
|
Datei/Neu/Projekt
"ASP.NET Web Application"
|
Projektdatei
|
Keine
|
.vbproj /
.csproj
|
Speicherung
von Projektkonfigurationsinformationen
|
Web.config
|
Projektdatei
|
Elemente
des Projekts definieren sich durch
|
Ordnerinhalt
|
Projektdatei
|
Aufnahme
in eine Projektmappe
|
Möglich
|
Möglich
|
Hinzufügen
von Dateien zum Projekt
|
Alle Dateien im
Wurzelordner und dessen Unterordnern gehören automatisch zum
Projekt
|
Nur Dateien, die
explizit aufgenommen wurden, gehören zum
Projekt.
|
Ausschluss
von einzelnen Dateien aus dem Projekt
|
Nur Dateien mit
der Dateiextension .excluded gelten aus
ausgeschlossen
|
Alle Dateien
können explizit ausgeschlossen werden.
|
Hinzufügen
von Ordnern zum Projekt
|
Alle Ordner in der
Ordnerhierarchie unterhalb des Wurzelordners gehören automatisch zum
Projekt, außer wenn sie als "IIS-Anwendung" im IIS angelegt
sind.
|
Nur Ordner, die
explizit aufgenommen wurden, gehören zum
Projekt.
|
Ausschluss
von einzelnen Ordnern aus dem Projekt
|
Nur über den Trick
möglich, dass die Website vom IIS geöffnet wird und der auszuschließende
Ordner eine eigene IIS-Anwendung ist.
|
Alle Ordner können
explizit ausgeschlossen werden.
|
IntelliSence
in der ASPX-Datei
|
Ja
|
Ja
|
Mischung
von verschiedenen Programmiersprachen in einem Projekt
|
Ja
|
Nein
|
Kompilierung
der ASPX-Dateien
|
In der
Entwicklungsumgebung möglich, aber nicht notwendig, da
ASP.NET-Autokompilierung beim ersten Aufruf wirkt
|
Nicht
möglich
|
Kompilierung
der Code-Behind-Dateien
|
In der
Entwicklungsumgebung möglich, aber nicht notwendig, da
ASP.NET-Autokompilierung beim ersten Aufruf wirkt
|
In der
Entwicklungsumgebung notwendig
|
Kompilierung
der eigenständigen Code-Dateien
|
In der
Entwicklungsumgebung möglich, aber nicht notwendig, da
ASP.NET-Autokompilierung beim ersten Aufruf wirkt
|
In der
Entwicklungsumgebung notwendig
|
Prüfung
der web.config-Dateien beim Kompilieren
|
Ja
|
Nein
|
Prüfung
der Eingabehilfen gemäß WCAG [10] und Access Board Section 508 [9]
|
Ja
|
Nein (wird sich
möglicherweise noch ändern)
|
Anzahl
der kompilierten Assemblies
|
Mehrere (eine
Assembly pro Sprache in /App_Code, eine weitere Assembly pro Dateiordner),
mehr Möglichkeiten gibt bei der Präkompilierung eines Projekts über die
Veröffentlichungsfunktion
|
Eine
(Code-Behind-Dateien + eigenständige
Code-Dateien)
|
Kompilieroptionen
in Visual Studio
|
·
Website
kompilieren
·
Einzelne Seite
kompilieren
·
Nichts
kompilieren
|
Webprojekt
kompilieren
|
Kompilierung
notwendig vor dem Betrachten von Seiten
|
Nein
|
Ja
|
Bearbeiten
und Fortsetzen während des Debuggens
|
Ja
|
Nein
|
Auslieferung
eines Projekts im komplett kompilierten Zustand
|
Möglich
|
Derzeit noch nicht
möglich (wird sich noch ändern durch Unterstützung in Web Deployment
Projekten, siehe [5])
|
Verweis
auf Code-Behind-Datei in Seitendirektive
|
CodeFile="MeineSeite.aspx.vb"
Inherits="MeineSeite"
|
CodeBehind="Anmelden.aspx.vb"
|
Erstellung
der Steuerelemente-Deklarationen für die Code-Behind-Datei
|
Automatisch im
Hintergrund (unsichtbar)
|
Automatisch durch
die Entwicklungsumgebung in der Datei Seite.Designer.cs bzw.
Seite.Designer.vb.
|
Standort
für eigenständige Code-Dateien
|
/App_Code
|
Jeder beliebige
Ort im Webprojekt
|
Setzen
von Referenzen
|
Eigenschaften
des Wurzelordners im Projektmappenexplorer
|
Ast
"Verweise" im Projektmappenexplorer
|
Speicherung
der Referenzen
|
Web.Config-Datei
(<compilation><assemblies>.)
|
Projektdatei
|
Unterstützung
für Quellcodeverwaltung
|
Ja
|
Ja
|
Unterstützung
für ASP.NET Development Server
|
Ja
|
Ja
|
Verschiedene
Übersetzungskonfigurationen
|
Nein
(nur möglich durch Web Deployment-Add-In)
|
Ja
|