(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde maschinell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

Vergleich von Webanwendungsprojekten und Websiteprojekten in Visual Studio

In Visual Studio können Sie Webanwendungsprojekte oder Websiteprojekte erstellen. Sie erstellen oder öffnen ein Webanwendungsprojekt, indem Sie Neues Projekt oder Projekt öffnen im Visual Studio-Menü Datei auswählen. Sie erstellen oder öffnen ein Websiteprojekt, indem Sie Neue Website oder Website öffnen im Menü Datei auswählen.

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 Hinweis

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

Dieses Thema enthält folgende Abschnitte:

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

  • Sie möchten in der Lage sein, die Bearbeiten und Fortfahren-Funktion des Visual Studio-Debuggers zu verwenden.

  • 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 verfügbar sind.

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

  • Sie möchten C#- und Visual Basic in ein einzelnes Webprojekt einschließen. (Standardmäßig, wird eine Webanwendung 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) ohne zu müssen zu aktualisieren die gesamte Site neu kompilieren.

  • Sie möchten den Quellcode auf dem Produktionsserver behalten, da er als zusätzliche Sicherungskopie fungieren kann.

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 enthält Tools, die mit Web Deploy (das IIS-Webbereitstellungstool) zusammenführen und 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 Tools für die Bereitstellung automatisieren, jedoch so viele Bereitstellungsaufgaben nicht die Tools, die für Webanwendungsprojekte.

Webanwendungsprojekte zeichnen Informationen zum Projekt mithilfe von Visual Studio-Projektdateien (.csproj oder .vbproj) auf. Dadurch ist es möglich, anzugeben, welche Dateien in das Projekt eingeschlossen bzw. daraus ausgeschlossen werden, wodurch das Dateien während eines Buildvorgangs kompiliert werden.

Für Websiteprojekte werden alle Dateien in einer Ordnerstruktur automatisch als enthalten in der Website betrachtet. Wenn Sie einige der Kompilierung ausschließen möchten, müssen Sie die Datei aus dem Websiteprojektordner entfernen oder die Dateinamenerweiterung in einer Erweiterung ändern, die nicht kompiliert und, nicht durch IIS bereitgestellt wird.

Ein Vorteil der Verwendung von Projektdateien in Webanwendungsprojekten ist Folgendes:

  • 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. Beispielsweise können Sie Dateien in das Projekt kopieren oder sie aus dem Projekt löschen, indem Sie Datei-Explorer verwenden.

Für Webanwendungsprojekte 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 ähnlich wie dem, was für Websiteprojekte.)

Bei Websiteprojekten müssen Sie das Projekt nicht manuell kompilieren. Websiteprojekte werden in der Regel dynamisch von ASP.NET kompiliert (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.

Vorteile 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, wenn Kompilierungsfehler in der Site auftreten, können Sie die Assembly erstellen und können sogar die Bestandteile der Website daher nicht testen, die kompilieren.)

  • 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 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. Die erste Anforderung an die Website muss die Site möglicherweise kompiliert werden, die eine Verzögerung führen kann. Und wenn die Website auf einem IIS-Server ausgeführt wird, auf dem wenig Arbeitsspeicher verfügbar ist, darunter die gesamte Site in einer einzelnen Assembly kann mehr Arbeitsspeicher, als verwenden für mehrere Assemblys erforderlich sind.

Um ein Webanwendungsprojekt bereitzustellen, kopieren Sie die Assembly die erstellt wird mit dem - Projekt auf einem IIS-Server kompiliert. Im Gegensatz dazu ein Websiteprojekt bereitzustellen, kopieren Sie die Projektquelldateien auf einen IIS-Server.

Vorteile 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 auf einem Entwicklungscomputer vorkompilieren und 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, die mit Webanwendungsprojekten, viele dieser Aufgaben zu automatisieren arbeiten. Diese Tools sind nicht für Websiteprojekte verfügbar.

Vorteile der Bereitstellungsstrategie für Websiteprojekte gehören:

  • Wenn Sie eine kleine Änderung zu einer Website vornehmen, müssen Sie die gesamte Site nicht 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, es sei denn, die einzige Änderung an einer ASPX- oder ASCX-Datei vorgenommen wurde.)

Community-Beiträge

Anzeigen:
© 2014 Microsoft