ASP.NET-Website oder ASP.NET-Webanwendung?


Answers

Die Website wird auf einem ASP.NET-Webserver wie IIS bereitgestellt. Nur ein paar Dateien und Ordner. Es gibt nichts auf einer Website, das Sie an Visual Studio bindet (es gibt keine Projektdatei). Code-Generierung und Kompilierung von Webseiten (wie .aspx, .ascx, .master) erfolgt dynamisch zur Laufzeit , und Änderungen an diesen Dateien werden vom Framework erkannt und automatisch neu kompiliert. Sie können Code, den Sie freigeben möchten, zwischen Seiten im speziellen Ordner App_Code platzieren, oder Sie können ihn vorab kompilieren und die Assembly in den Ordner Bin stellen.

Web Application ist ein spezielles Visual Studio-Projekt. Der Hauptunterschied zu Websites besteht darin, dass beim Erstellen des Projekts alle Codedateien in einer einzelnen Assembly kompiliert werden, die im Verzeichnis bin abgelegt wird. Sie stellen keine Code-Dateien auf dem Webserver bereit. Anstatt einen speziellen Ordner für gemeinsam genutzte Code-Dateien zu haben, können Sie sie überallhin platzieren, genau wie in der Klassenbibliothek. Da Webanwendungen Dateien enthalten, die nicht bereitgestellt werden sollen, z. B. Projekt- und Codedateien, gibt es in Visual Studio einen Befehl zum Veröffentlichen, um eine Website an einen bestimmten Speicherort auszugeben.

App_Code vs Bin

Das Bereitstellen von freigegebenen Codedateien ist normalerweise eine schlechte Idee, aber das bedeutet nicht, dass Sie Webanwendung auswählen müssen. Sie können eine Website erstellen, die auf ein Klassenbibliotheksprojekt verweist, das den gesamten Code für die Website enthält. Web-Anwendungen sind nur eine bequeme Möglichkeit, dies zu tun.

CodeBehind

Dieses Thema ist spezifisch für .aspx- und .ascx-Dateien. Dieses Thema ist in neuen Anwendungsframeworks wie ASP.NET MVC und ASP.NET-Webseiten, die keine Codebehind-Dateien verwenden, immer weniger relevant.

Wenn Sie alle Code-Dateien in eine einzelne Assembly kompiliert haben, einschließlich der codebehind- Dateien von ASPX-Seiten und .ascx-Steuerelementen, müssen Sie in Webanwendungen für jede kleine Änderung neu erstellen, und Sie können keine Live-Änderungen vornehmen. Dies kann während der Entwicklung sehr schmerzhaft sein, da Sie die Änderungen ständig neu erstellen müssen, während bei Websites Änderungen von der Laufzeit erkannt werden und Seiten / Steuerelemente automatisch neu kompiliert werden.

Das Verwalten der Codebehind-Assemblys mit der Laufzeit ist für Sie weniger arbeitsaufwendig, da Sie sich keine Gedanken darüber machen müssen, wie Sie eindeutigen Seiten / Steuerelementen Namen geben oder sie in verschiedenen Namespaces organisieren.

Ich sage nicht, das Bereitstellen von Code-Dateien ist immer eine gute Idee (speziell nicht im Fall von gemeinsam genutzten Code-Dateien), aber CodeBehind-Dateien sollten nur Code enthalten, die UI-spezifische Aufgaben, Draht-Event-Handler usw. Ihre Anwendung sollte sein so dass wichtiger Code immer im Bin-Ordner landet. Wenn dies der Fall ist, sollte die Bereitstellung von Codebehind-Dateien nicht als schädlich angesehen werden.

Eine weitere Einschränkung von Web-Anwendungen besteht darin, dass Sie nur die Sprache des Projekts verwenden können. In Websites können Sie einige Seiten in C #, einige in VB, etc. haben. Keine Notwendigkeit für spezielle Visual Studio-Unterstützung. Das ist die Schönheit der Erweiterbarkeit des Build-Providers.

Außerdem erhalten Sie in Web Applications keine Fehlererkennung in Pages / Controls, da der Compiler nur Ihre CodeBehind-Klassen kompiliert und nicht den Markup-Code (in MVC können Sie dies mit der Option MvcBuildViews beheben), der zur Laufzeit kompiliert wird.

Visual Studio

Da Webanwendungen Visual Studio-Projekte sind, erhalten Sie einige Funktionen, die auf Websites nicht verfügbar sind. Zum Beispiel können Sie Build-Ereignisse verwenden, um eine Vielzahl von Aufgaben auszuführen, z. B. Minimieren und / oder Kombinieren von Javascript-Dateien.

Ein weiteres nettes Feature in Visual Studio 2010 ist die Web.config-Umwandlung . Dies ist auch nicht in Websites verfügbar. Funktioniert jetzt mit Websites in VS 2013.

Das Erstellen einer Webanwendung ist schneller als das Erstellen einer Website speziell für große Websites. Dies liegt hauptsächlich daran, dass Web-Anwendungen den Markup-Code nicht kompilieren. Wenn Sie in MVC MvcBuildViews auf true setzen, kompiliert es den Markup-Code und Sie erhalten eine Fehlererkennung, was sehr nützlich ist. Der Nachteil ist, dass jedes Mal, wenn Sie die Lösung erstellen, die komplette Site erstellt wird, was langsam und ineffizient sein kann, besonders wenn Sie die Site nicht bearbeiten. Ich finde, dass ich MvcBuildViews ein- und ausschalte (was ein Projekt-Entladen erfordert). Auf der anderen Seite können Sie bei Websites auswählen, ob Sie die Site als Teil der Lösung erstellen möchten oder nicht. Wenn Sie dies nicht tun, ist das Erstellen der Lösung sehr schnell und Sie können immer auf den Knoten Website klicken und Build auswählen, wenn Sie Änderungen vorgenommen haben.

In einem MVC-Webanwendungsprojekt verfügen Sie über zusätzliche Befehle und Dialoge für allgemeine Aufgaben wie "Ansicht hinzufügen", "Gehe zu Ansicht", "Controller hinzufügen" usw. Diese sind auf einer MVC-Website nicht verfügbar.

Wenn Sie IIS Express als Entwicklungsserver verwenden, können Sie in Websites virtuelle Verzeichnisse hinzufügen. Diese Option ist in Webanwendungen nicht verfügbar.

Die NuGet-Paketwiederherstellung funktioniert nicht auf Websites. Sie müssen die in der Datei packages.config aufgeführten Pakete manuell installieren Die Paketwiederherstellung funktioniert jetzt mit Websites , auf denen NuGet 2.7 gestartet wird

Question

Wenn ich ein neues ASP.NET-Projekt in Visual Studio starte, kann ich eine ASP.NET-Webanwendung erstellen oder eine ASP.NET-Website erstellen.

Was ist der Unterschied zwischen der ASP.NET-Webanwendung und der ASP.NET-Website? Warum sollte ich einen anderen wählen?

Ist die Antwort abhängig davon, welche Version von Visual Studio ich verwende, unterschiedlich?




Sofern Sie nicht ausdrücklich ein dynamisch kompiliertes Projekt benötigen , verwenden Sie kein Website-Projekt .

Warum? Weil das Website-Projekt Sie an die Wand treibt, wenn Sie versuchen, Ihr Projekt zu ändern oder zu verstehen. Die statischen Typisierungsfunktionen (z. B. Verwendungen finden, Refactor) in Visual Studio werden bei jedem Projekt mit vernünftiger Größe dauern. Weitere Informationen finden Sie in der Stapelüberlauf-Frage Slow "Alle Referenzen suchen" in Visual Studio .

Ich kann wirklich nicht sehen, warum sie Web-Anwendungen in Visual Studio 2005 für den Projekttyp "Schmerz verursachende, geistig ablaufende, produktive Carbuncle-Websites" fallen gelassen haben.




Das klingt vielleicht einleuchtend, aber ich denke, dass es etwas missverstanden ist, weil Visual Studio 2005 ursprünglich nur mit der Website geliefert wurde. Wenn Ihr Projekt eine Website betrifft, die ziemlich begrenzt ist und keine logische oder physische Trennung aufweist, ist die Website in Ordnung. Wenn es sich jedoch wirklich um eine Webanwendung mit verschiedenen Modulen handelt, bei denen viele Benutzer Daten hinzufügen und aktualisieren, ist die Webanwendung besser.

Der größte app_code des Website-Modells ist, dass alles im Abschnitt app_code dynamisch kompiliert wird. Sie können Aktualisierungen der C # -Datei ohne eine vollständige erneute Bereitstellung vornehmen. Dies ist jedoch ein großes Opfer. Unter den schwer kontrollierbaren Abdeckungen passieren viele Dinge. Namespaces sind schwer zu kontrollieren, und die spezifische DLL-Verwendung wird standardmäßig für alles unter app_code da alles dynamisch kompiliert wird.

Das Webanwendungsmodell hat keine dynamische Kompilierung, aber Sie haben die Kontrolle über die Dinge, die ich erwähnt habe.

Wenn Sie eine n-Tier-Entwicklung durchführen, empfehle ich das Webanwendungsmodell. Wenn Sie eine begrenzte Website oder eine schnelle und schmutzige Implementierung durchführen, kann das Website-Modell Vorteile haben.

Eine detailliertere Analyse finden Sie in:




Es hängt davon ab, was Sie entwickeln.

Bei einer inhaltsorientierten Website ändert sich der Inhalt häufig und eine Website ist dafür besser geeignet.

Eine Anwendung neigt dazu, ihre Daten in einer Datenbank speichern zu lassen, und ihre Seiten und ihr Code ändern sich selten. In diesem Fall ist es besser, über eine Webanwendung zu verfügen, bei der die Bereitstellung von Baugruppen viel besser gesteuert wird und die Komponententests besser unterstützt werden.




Einer der Hauptunterschiede besteht darin, dass Websites dynamisch kompiliert und On-The-Fly-Assemblys erstellt werden. Web-Anwendungen werden in einer großen Assembly kompiliert.

Die Unterscheidung zwischen den beiden wurde in Visual Studio 2008 aufgehoben.




Anwendungen werden in der Regel vor der Bereitstellung kompiliert, da die Website das Verzeichnis app_code verwendet. Wenn sich im App-Code-Ordner etwas ändert, kompiliert der Server den Code erneut. Dies bedeutet, dass Sie Code mit einer Website im laufenden Betrieb hinzufügen / ändern können.

Der Vorteil einer App besteht darin, dass keine Neukompilierung erforderlich ist und die anfänglichen Startzeiten schneller sind.




Eine "Website" hat ihren Code in einem speziellen App_Code-Verzeichnis und wird zur Laufzeit in mehrere DLLs (Assemblies) kompiliert. Eine "Webanwendung" wird in einer einzelnen DLL vorkompiliert.




Web Application-Projektmodell

  • Stellt die gleiche Webprojektsemantik wie Visual Studio .NET-Webprojekte bereit. Hat eine Projektdatei (Struktur basiert auf Projektdateien). Modell erstellen - Der gesamte Code im Projekt wird in einer einzelnen Assembly kompiliert. Unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server. Unterstützt alle Funktionen von Visual Studio 2005 (Refactoring, Generics usw.) und von ASP.NET (Masterseiten, Mitgliedschaft und Login, Websitenavigation, Themen usw.). Die Verwendung von FrontPage-Servererweiterungen (FPSE) ist nicht mehr erforderlich.

Website-Projektmodell

  • Keine Projektdatei (basierend auf dem Dateisystem).
  • Neues Kompilierungsmodell
  • Dynamisches Kompilieren und Bearbeiten von Seiten, ohne die gesamte Site auf jeder Seitenansicht zu erstellen.
  • Unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server.
  • Jede Seite hat ihre eigene Assembly.
  • Defferent Code-Modell.



In Webanwendungsprojekten benötigt Visual Studio zusätzliche .designer-Dateien für Seiten und Benutzersteuerelemente. Website-Projekte benötigen diesen Aufwand nicht. Das Markup selbst wird als Design interpretiert.




Webanwendungen benötigen mehr Arbeitsspeicher, vermutlich weil Sie keine andere Wahl haben, als in eine einzelne Assembly zu kompilieren. Ich habe gerade eine große Legacy-Site in eine Web-Anwendung umgewandelt und habe Probleme, dass nicht genügend Arbeitsspeicher zur Verfügung steht

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

Fehler und zur Laufzeit mit diesem Fehler:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

Meine Empfehlung für die Konvertierung größerer Sites auf Alias-Hardware mit Speicherbeschränkung ist, dass Sie die Möglichkeit haben, auf das Websitemodell zurückzugreifen. Auch nach einem anfänglichen Erfolg könnten später Probleme auftreten.




Definitiv Web-Anwendung, einzelne DLL-Datei und einfach zu pflegen. Aber eine Website ist flexibler; Sie können die aspx-Datei unterwegs bearbeiten.




Websites - Es wird keine Lösungsdatei erstellt. Wenn wir Websites erstellen möchten, brauchen Sie kein visuelles Studio.

Web Application - Eine Lösungsdatei wird erstellt. Wenn wir Webanwendungen erstellen möchten, sollten Sie das Visual Studio benötigen. Es wird eine einzelne .dll Datei im bin-Ordner erstellt.