Vergleich von Webanwendungsprojekten und Websiteprojekten

Artikel
10/15/2014

In Visual Studio können Sie Webanwendungsprojekte oder Websiteprojekte erstellen. Jeder Projekttyp weist Vorteile und Nachteile auf. Daher ist es hilfreich, die Unterschiede zwischen den verschiedenen Typen zu kennen, um den für Ihre Zwecke am besten geeigneten Typ zu wählen. Sie müssen den entsprechenden Projekttyp auswählen, bevor Sie ein Projekt erstellen, da die Konvertierung von einem Projekttyp in einen anderen nicht praktikabel ist.

Hinweis

Bei einigen Szenarien haben Sie keine Wahl.Wenn Sie z. B. eine ASP.NET-MVC-Anwendung erstellen möchten, müssen Sie ein Webanwendungsprojekt verwenden.

Dieses Thema enthält folgende Abschnitte:

Szenarien
Zusammenfassung der Unterschiede
Projektdateistruktur
Kompilierung
Bereitstellung

Szenarien

Zu Szenarien, in denen Webanwendungsprojekte die bevorzugte Auswahl sind, gehören die Folgenden:

Sie möchten in der Lage sein, Code ohne Beendigung einer Debugsitzung zu bearbeiten.
Sie möchten Komponententests für Code ausführen, der in den Klassendateien enthalten ist, die ASP.NET-Seiten zugeordnet sind.
Sie möchten auf die Klassen verweisen, die Seiten und Benutzersteuerelementen von eigenständigen Klassen zugeordnet sind.
Sie möchten Projektabhängigkeiten von mehreren Webprojekten festlegen.
Sie möchten, dass der Compiler eine einzige Assembly für die gesamte Site erstellt.
Sie möchten Kontrolle über den Assemblynamen und die Versionsnummer, die für die Site generiert werden.
Sie möchten MSBuild oder Team Build verwenden, um das Projekt zu kompilieren. Sie möchten beispielsweise Präbuild- und Postbuildschritte hinzufügen.
Sie möchten vermeiden, dass Quellcode auf einem Produktionsserver abgelegt wird.
Sie möchten die automatisierten Bereitstellungstools verwenden, die in Visual Studio 2010 verfügbar sind.

Zu Szenarien, in denen Websiteprojekte die bevorzugte Auswahl sind, gehören die Folgenden:

Sie möchten sowohl C# als auch Visual Basic-Code in ein einzelnes Webprojekt einschließen. (Standardmäßig werden Webanwendungen auf Grundlage der Spracheinstellungen in der Projektdatei kompiliert. Ausnahmen können gemacht werden, doch dies ist relativ schwierig.)
Sie möchten die Produktionswebsite in Visual Studio öffnen und sie in Echtzeit mit FTP aktualisieren.
Sie möchten nicht dazu gezwungen sein, das Projekt explizit zu kompilieren, um es bereitzustellen.
Wenn Sie die Website vorab kompilieren, möchten Sie, dass der Compiler mehrere Assemblys für die Website erstellt, was eine Assembly pro Seite oder Benutzersteuerelement oder mindestens eine Assembly pro Ordner umfassen kann.
Sie möchten in der Lage sein, einzelne Dateien in der Produktion zu aktualisieren, indem Sie einfach neue Versionen auf den Produktionsserver kopieren oder indem Sie die Dateien direkt auf dem Produktionsserver bearbeiten.
Wenn Sie die Website vorkompilieren, möchten Sie in der Lage sein, einzelne ASP.NET-Webseiten (ASPX-Dateien) zu aktualisieren, ohne die gesamte Website neu kompilieren zu müssen.
Sie möchten den Quellcode auf dem Produktionsserver behalten, da er als zusätzliche Sicherungskopie fungieren kann.

Zusammenfassung der Unterschiede

In der folgenden Tabelle werden die Hauptunterschiede zusammengefasst.

Bereich	Webanwendungsprojekte	Websiteprojekte
Projektdateistruktur	Eine Visual Studio-Projektdatei (.csproj oder .vbproj) speichert Informationen zum Projekt, z. B. die Liste der Dateien, die im Projekt enthalten sind, sowie alle Verweise von Projekt zu Projekt.	Es gibt keine Projektdatei (.csproj oder .vbproj). Alle Dateien in einer Ordnerstruktur sind automatisch in der Site enthalten.
Kompilierung	Sie kompilieren den Quellcode explizit auf dem Computer, der für Entwicklung oder Quellcodeverwaltung verwendet wird. Standardmäßig wird bei der Kompilierung von Codedateien (mit Ausnahme von ASPX- und ASCX-Dateien) eine einzige Assembly erstellt.	Der Quellcode wird in der Regel dynamisch (automatisch) von ASP.NET auf dem Server kompiliert, wenn zum ersten Mal eine Anforderung empfangen wird, nachdem die Site installiert oder aktualisiert wurde. Sie können die Site vorkompilieren (d. h. im Voraus auf einem Entwicklungscomputer oder auf dem Server kompilieren). Standardmäßig werden bei der Kompilierung mehrere Assemblys erstellt.
Namespaces	Explizite Namespaces werden standardmäßig Seiten, Steuerelementen und Klassen hinzugefügt.	Explizite Namespaces werden nicht standardmäßig Seiten, Steuerelementen und Klassen hinzugefügt, können aber manuell hinzugefügt werden.
Bereitstellung	Sie kopieren die Assembly auf einen Server. Die Assembly wird durch Kompilierung der Anwendung erstellt. Visual Studio stellt Tools bereit, die in das IIS-Webbereitstellungstool integriert werden können, sodass viele Bereitstellungsaufgaben automatisiert werden können.	Sie kopieren die Anwendungsquelldateien auf einen Computer, auf dem IIS installiert ist. Wenn Sie die Site auf einem Entwicklungscomputer vorkompilieren, kopieren Sie die durch die Kompilierung erstellten Assemblys auf den IIS-Server. Visual Studio stellt zwar Tools für die Bereitstellung bereit, durch diese werden jedoch nicht so viele Bereitstellungsaufgaben automatisiert wie durch die Tools für Webanwendungsprojekte.

Projektdateistruktur

Webanwendungsprojekte zeichnen Informationen zum Projekt mithilfe von Visual Studio-Projektdateien (.csproj oder .vbproj) auf. Unter anderem kann auf diese Weise angegeben werden, welche Dateien in das Projekt eingeschlossen bzw. daraus ausgeschlossen werden und welche Dateien daher während eines Buildvorgangs kompiliert werden.

Bei Websiteprojekten wird von allen Dateien in einer Ordnerstruktur automatisch davon ausgegangen, dass sie in der Website enthalten sind. Wenn Sie ein Elemente von der Kompilierung ausschließen möchten, müssen Sie die Datei aus dem Websiteprojektordner entfernen oder ihre Dateinamenerweiterung in eine Erweiterung ändern, die nicht kompiliert und von IIS nicht verarbeitet wird.

Ein Vorteil der Verwendung von Projektdateien in Webanwendungsprojekten besteht beispielsweise in Folgendem:

Dateien können problemlos vorübergehend von der Site entfernt werden, Sie müssen jedoch sicherstellen, dass Sie weiterhin den Überblick über diese Dateien behalten, da Sie in der Ordnerstruktur verbleiben. Wenn eine Seite beispielsweise noch nicht bereitgestellt werden kann, können Sie sie vorübergehend aus dem Buildvorgang ausschließen, ohne sie aus der Ordnerstruktur zu löschen. Sie können die kompilierte Assembly bereitstellen und dann die Datei erneut in das Projekt einschließen. Dies ist besonders wichtig, wenn Sie mit einem Quellcodeverwaltungsrepository arbeiten.

Ein Vorteil der Verwendung einer Ordnerstruktur ohne Projektdateien in Websiteprojekten besteht beispielsweise in Folgendem:

Sie müssen die Struktur des Projekts nicht ausschließlich in Visual Studio verwalten. Sie können z. B. Dateien in das Projekt kopieren oder sie mit Windows-Explorer aus dem Projekt löschen.

Kompilierung

Bei Webanwendungsprojekten erstellen Sie das Projekt in der Regel in Visual Studio oder mit dem ASP.NET-Batchcompiler auf einem Computer, der nicht der IIS-Produktionsserver ist. Alle Code-Behind-Klassendateien und eigenständigen Klassendateien im Projekt werden in eine einzige Assembly kompiliert, die dann im Ordner "Bin" des Webanwendungsprojekts platziert wird. (Die ASPX- und ASCX-Dateien werden dynamisch ähnlich wie Websiteprojekte kompiliert.)

Bei Websiteprojekten müssen Sie das Projekt nicht manuell kompilieren. Websiteprojekte werden in der Regel dynamisch von ASP.NET kompiliert (sowohl auf dem Entwicklungscomputer als auch auf dem IIS-Produktionsserver). Sie können zwischen dem Batchkompilierungsmodus, bei dem in der Regel eine Assembly pro Ordner erstellt wird, und dem festen Kompilierungsmodus wählen, bei dem in der Regel eine Assembly für jede Seite oder jedes Benutzersteuerelement erstellt wird.

Zu den Vorteilen des Kompilierungsmodells für Webanwendungsprojekte gehören:

Sie können mithilfe von MSBuild einen benutzerdefinierten Batchkompilierungprozess erstellen.
Assemblyattribute wie Name und Version können leicht angegeben werden.
Die Kompilierung im Voraus hat den Vorteil, dass Benutzer nicht warten müssen, während die Site auf dem Produktionsserver kompiliert wird. (Wenn die Site sehr groß ist, kann die dynamische Kompilierung eines Websiteprojekts sehr lange dauern. Die dynamische Kompilierung tritt auf, wenn eine Anforderung für eine Siteressource nach einer Aktualisierung der Site empfangen wird, und die Anforderung, durch die die Kompilierung ausgelöst wird, verzögert wird, während die erforderlichen Ressourcen kompiliert werden. Wenn die Verzögerung inakzeptabel ist, können Sie die Site vorkompilieren. Dabei werden jedoch einige Vorteile der dynamischen Kompilierung zunichte gemacht.)
Sie haben die volle Kontrolle darüber, wo Sie die Codedateien in der Projektordnerstruktur platzieren und wie Klassen in dem Projekt aufeinander verweisen. (Die dynamische Kompilierung erfordert, dass sich der Quellcode für alle Klassen, die in der gesamten Site verwendet werden, im Ordner "App_Code" befindet. Sie können nicht von einer Klasse im Ordner "App_Code" auf eine Seite oder eine Benutzersteuerelementklasse verweisen.)

Zu den Vorteilen des Kompilierungsmodells für Websiteprojekte gehören:

Sie können bestimmte Seiten unabhängig vom Zustand anderer Seiten testen. Das liegt daran, dass für das Ausführen einer einzelnen Seite nicht die gesamte Site erfolgreich kompiliert werden muss, sondern nur die Seite und Komponenten, die davon abhängig sind, z. B. Code im Ordner "App_Code" oder in der Datei "Global.asax". (In einem Webanwendungsprojekt, können Sie, wenn Kompilierungsfehler in der Site auftreten, die Assembly nicht erstellen und daher nicht einmal die Teile der Site testen, die kompiliert werden können.)
Eine Website in Produktion kann problemlos aktualisiert werden. Sie können einzelne Quellcodedateien auf dem Produktionsserver aktualisieren, ohne die Site explizit erneut kompilieren zu müssen. Sie können einzelne Dateien aktualisieren, die zur Bereitstellung bereit sind, auch wenn andere Dateien aufgrund von Compilerfehlern nicht bereit sind. Sie können die Website auch auf dem IIS-Produktionsserver direkt in Visual Studio öffnen und die Website in Echtzeit aktualisieren.
Das Vorkompilieren mehrerer Assemblys kann in einigen Szenarien einen Leistungsvorteil bieten. Ein typisches Beispiel hierfür ist eine Site, die viele Seiten mit einer großen Menge Code aufweist, der für die Seiten geschrieben wurde. Die meisten Seiten werden selten und angefordert; nur einige werden häufig verwendet. Wenn Sie eine solche Site in mehrerer Assemblys kompilieren, kann der Produktionsserver nur die Assemblys laden, die für die aktuellen Anforderungen erforderlich sind. Wenn eine Seite nicht angefordert wird, wird ihre entsprechende Assembly nicht geladen.

Hinweis

Es gibt keinen Leistungsunterschied zwischen einem Websiteprojekt und einem Webanwendungsprojekt.Die einzigen bedeutenden Ausnahmen sind die, die bereits erwähnt wurden, und aus praktischen Gründen treffen diese nur auf sehr große Sites zu.Bei der ersten Anfrage an die Website muss die Site möglicherweise kompiliert werden, was zu einer Verzögerung führen kann.Und wenn die Website auf einem IIS-Server ausgeführt wird, auf dem wenig Arbeitsspeicher verfügbar ist, kann sogar die gesamte Site in einer einzigen Assembly mehr Arbeitsspeicher verbrauchen als für mehrere Assemblys erforderlich wäre.

Bereitstellung

Um ein Webanwendungsprojekt bereitzustellen, kopieren Sie die Assembly, die durch Kompilieren des Projekts erstellt wird, auf einen IIS-Server. Im Gegensatz dazu werden zum Bereitstellen eines Websiteprojekts in der Regel die Projektquelldateien auf einen IIS-Server kopiert.

Zu den Vorteilen der Bereitstellungsstrategie für Webanwendungsprojekte gehören:

Sie müssen keinen Quellcode auf dem IIS-Server bereitstellen. In einigen Szenarien, z. B. in freigegebenen Hostumgebungen, befürchten Sie möglicherweise nicht autorisierten Zugriff auf Quellcode auf dem IIS-Server. (Bei einem Websiteprojekt können Sie dieses Risiko minimieren, indem Sie eine Vorkompilierung auf einem Entwicklungscomputer durchführen und dann die generierten Assemblys anstatt des Quellcodes bereitstellen.) In diesem Fall gehen jedoch einige der Vorteile einfacher Siteupdates verloren.)
Die Bereitstellung schließt neben dem Kopieren von Assemblys oder Code auf einen Server häufig auch andere Aufgaben mit ein. Datenbankskripts müssen sich beispielsweise in Produktion befinden, und Verbindungszeichenfolgen in der Datei "Web.config" müssen für einen Produktionsserver möglicherweise geändert werden. Visual Studio stellt Tools wie One-Click-Veröffentlichung bereit, die bei Webanwendungsprojekten zum Automatisieren eines Großteils dieser Aufgaben verwendet werden können. Diese Tools sind nicht für Websiteprojekte verfügbar.

Zu den Vorteilen der Bereitstellungsstrategie für Websiteprojekte gehören:

Wenn Sie an einer Webanwendung eine kleine Änderung vornehmen, müssen Sie nicht die gesamte Anwendung erneut bereitstellen. Sie können stattdessen nur die geänderte Datei bzw. die geänderten Dateien auf den IIS-Produktionsserver kopieren. Sie können Dateien auch direkt auf dem Produktionsserver bearbeiten. (Da die Codedateien eines Webanwendungsprojekts in eine einzige Assemblydatei kompiliert werden, müssen Sie die gesamte Site sogar für kleine Änderungen bereitstellen, außer wenn die einzige Änderung an einer ASPX- oder ASCX-Datei vorgenommen wurde.)