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


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?



Answers



Webseite:

Das Website- Projekt wird im laufenden Betrieb kompiliert. Sie am Ende mit viel mehr DLL-Dateien, die ein Schmerz sein können. Es gibt auch Probleme, wenn Sie Seiten oder Steuerelemente in einem Verzeichnis haben, die auf Seiten und Steuerelemente in einem anderen Verzeichnis verweisen müssen, da das andere Verzeichnis möglicherweise noch nicht in Code kompiliert wurde. Ein anderes Problem kann in der Veröffentlichung sein.

Wenn Visual Studio nicht aufgefordert wird, dieselben Namen ständig zu verwenden, werden neue Namen für die DLL-Dateien erstellt, die ständig von Seiten generiert werden. Das kann dazu führen, dass mehrere DLL-Dateien, die den gleichen Klassennamen enthalten, mehrere Kopien haben, was zu vielen Fehlern führen wird. Das Website-Projekt wurde mit Visual Studio 2005 eingeführt, es hat sich jedoch herausgestellt, dass es nicht sehr beliebt ist.

Internetanwendung:

Das Webanwendungsprojekt wurde als Add-In erstellt und ist jetzt als Teil von SP 1 für Visual Studio 2005 vorhanden. Die Hauptunterschiede bestehen darin, dass das Webanwendungsprojekt so konzipiert wurde, dass es ähnlich wie die Webprojekte von Visual Studio 2003 funktioniert kompilieren Sie die Anwendung zur Build-Zeit in eine einzelne DLL-Datei. Um das Projekt zu aktualisieren, muss es neu kompiliert werden und die DLL-Datei für Änderungen veröffentlicht werden.

Eine weitere nette Eigenschaft des Web Application-Projekts ist, dass es viel einfacher ist, Dateien von der Projektansicht auszuschließen. In dem Projekt Website wird jede Datei, die Sie ausschließen, mit einem Ausschlussschlüsselwort in dem Dateiname umbenannt. Im Webanwendungsprojekt verfolgt das Projekt einfach, welche Dateien in die Projektansicht aufgenommen / ausgeschlossen werden sollen, ohne sie umzubenennen, wodurch die Dinge viel aufgeräumter werden.

Referenz

Der Artikel ASP.NET 2.0 - Website versus Web Application-Projekt gibt auch Gründe dafür, warum man das eine und nicht das andere verwenden soll. Hier ist ein Auszug davon:

  • Sie müssen große Visual Studio .NET 2003-Anwendungen zu VS 2005 migrieren? Verwenden Sie das Webanwendungsprojekt.
  • Sie möchten ein beliebiges Verzeichnis als Webprojekt öffnen und bearbeiten, ohne eine Projektdatei zu erstellen? Verwenden Sie das Website-Projekt.
  • Sie müssen während der Kompilierung Pre-Build- und Post-Build-Schritte hinzufügen. Verwenden Sie das Webanwendungsprojekt.
  • Sie müssen eine Webanwendung mit mehreren Webprojekten erstellen? Verwenden Sie das Webanwendungsprojekt.
  • Sie möchten für jede Seite eine Assembly generieren? Verwenden Sie das Website-Projekt.
  • Sie bevorzugen das dynamische Kompilieren und Bearbeiten von Seiten, ohne dass auf jeder Seitenansicht eine komplette Website erstellt werden muss? Verwenden Sie das Website-Projekt.
  • Sie bevorzugen ein einseitiges Code-Modell zum Code-Behind-Modell? Verwenden Sie das Website-Projekt.

Webanwendungsprojekte im Vergleich zu Websiteprojekten (MSDN) erläutert die Unterschiede zwischen Website- und Webanwendungsprojekten. Außerdem wird die Konfiguration in Visual Studio erläutert.




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




Website = verwenden, wenn die Website von Grafikern erstellt wird und die Programmierer nur eine oder zwei Seiten bearbeiten

Web Application = Wird verwendet, wenn die Anwendung von Programmierern erstellt wird und die Grafikdesigner nur ein oder zwei Seiten / Bilder bearbeiten.

Websites können mit beliebigen HTML-Tools bearbeitet werden, ohne dass Entwicklerstudio benötigt wird, da Projektdateien nicht aktualisiert werden müssen. Webanwendungen sind am besten, wenn das Team hauptsächlich Entwicklerstudio verwendet und ein hoher Code-Inhalt vorhanden ist.

(Einige Codierungsfehler werden in Webanwendungen zur Kompilierungszeit gefunden, die bis zur Laufzeit nicht in Websites gefunden werden.)

Warnung: Ich habe diese Antwort vor vielen Jahren geschrieben und seither Asp.net nicht mehr benutzt. Ich gehe davon aus, dass sich die Dinge jetzt weiter entwickelt haben.




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:




Aus dem MCTS-selbstlernenden Trainingssatz-Examen 70-515 Buch:

Mit Web-Anwendung (Projekt),

  1. Sie können eine MVC-Anwendung erstellen.
  2. Visual Studio speichert die Liste der Dateien in einer Projektdatei (.csproj oder .vbproj), anstatt sich auf die Ordnerstruktur zu verlassen.
  3. Sie können Visual Basic und C # nicht mischen.
  4. Sie können Code nicht bearbeiten, ohne eine Debugging-Sitzung anzuhalten.
  5. Sie können Abhängigkeiten zwischen mehreren Webprojekten herstellen.
  6. Sie müssen die Anwendung vor der Bereitstellung kompilieren, was verhindert, dass Sie eine Seite testen, wenn eine andere Seite nicht kompiliert wird.
  7. Sie müssen den Quellcode nicht auf dem Server speichern.
  8. Sie können den Assemblynamen und die Version steuern.
  9. Sie können einzelne Dateien nach der Bereitstellung nicht erneut kompilieren.



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.




Compilation Zunächst gibt es einen Unterschied in der Zusammenstellung. Die Website ist nicht auf dem Server vorkompiliert, sie ist in einer Datei kompiliert. Es kann ein Vorteil sein, denn wenn Sie etwas auf Ihrer Website ändern möchten, können Sie einfach eine bestimmte Datei vom Server herunterladen, ändern und diese Datei zurück auf den Server hochladen und alles würde gut funktionieren. In der Web-Anwendung können Sie dies nicht tun, weil alles vorkompiliert ist und Sie nur mit einer DLL enden. Wenn Sie etwas in einer Datei Ihres Projekts ändern, müssen Sie alles erneut kompilieren. Also, wenn Sie eine Möglichkeit haben möchten, einige Dateien auf der Server-Website zu ändern, ist eine bessere Lösung für Sie. Es ermöglicht auch vielen Entwicklern, auf einer Website zu arbeiten. Auf der anderen Seite sollten Sie, wenn Sie nicht möchten, dass Ihr Code auf dem Server verfügbar ist, die Webanwendung wählen. Diese Option eignet sich auch besser für Komponententests, da nach dem Veröffentlichen Ihrer Website eine DLL-Datei erstellt wird.

Project structure Es gibt auch einen Unterschied in der Struktur des Projekts. In der Web Application haben Sie eine Projektdatei, so wie Sie sie in der normalen Anwendung hatten. In der Website gibt es keine traditionelle Projektdatei, Sie haben nur eine Lösungsdatei. Alle Verweise und Einstellungen sind in der Datei web.config gespeichert. @Page directive Es gibt ein anderes Attribut in der @ Page-Direktive für die Datei, die die Klasse enthält, die dieser Seite zugeordnet ist. In Web-Anwendung ist es Standard "CodeBehind", in der Website verwenden Sie "CodeFile". Sie können dies in den folgenden Beispielen sehen:

Web Application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

Webseite:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

Namespaces - Im obigen Beispiel sehen Sie auch einen anderen Unterschied - wie Namespaces erstellt werden. Im Web Application-Namespace ist einfach ein Name des Projekts. In der Website gibt es den Standard-Namespace-ASP für dynamisch kompilierte Seiten.

Edit and Continue - In der Web Application Edit und Continue-Option ist verfügbar (um es zu aktivieren, müssen Sie im Menü Extras, klicken Sie auf Optionen, dann finden Sie Bearbeiten und Weiter im Debuggen). Diese Funktion funktioniert nicht in Web Site.ASP.NET MVCIf, mit der Sie Webanwendungen entwickeln möchten

ASP.NET MVC (Model View Controller) die beste und Standardoption ist Web Application. Obwohl es möglich ist, MVC in der Website zu verwenden, wird es nicht empfohlen.

Zusammenfassung - Der wichtigste Unterschied zwischen der ASP.NET-Webanwendung und der Website ist die Kompilierung. Wenn Sie also an einem größeren Projekt arbeiten, an dem einige Personen Änderungen vornehmen können, ist es besser, die Website zu verwenden. Aber wenn Sie ein kleineres Projekt machen, können Sie auch die Web-Anwendung verwenden.




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.




Ja Web-Anwendung ist viel besser als Websites, weil Web-Anwendungen uns Freiheit geben:

  1. Um mehrere Projekte unter einem Dach zu haben und Projektabhängigkeiten herzustellen. ZB für PCS können wir folgende Webanwendungen haben:

    • Webportale
    • Benachrichtigungs-Controller (zum Senden von E-Mails)
    • Geschäftsschicht
    • Datenzugriffsschicht
    • Ausnahmemanager
    • Server-Dienstprogramm
    • WCF-Dienste (allgemein für alle Plattformen)
    • Listenpunkt
  2. So führen Sie Komponententests für Code aus, der sich in den Klassendateien befindet, die ASP.NET-Seiten zugeordnet sind

  3. Um auf die Klassen zu verweisen, die mit Seiten und Benutzersteuerelementen aus eigenständigen Klassen verknüpft sind
  4. So erstellen Sie eine einzelne Assembly für die gesamte Site
  5. Steuern Sie den Assemblynamen und die Versionsnummer, die für die Site generiert werden
  6. Um zu vermeiden, dass Quellcode auf einen Produktionsserver gestellt wird. (Sie können die Bereitstellung von Quellcode für den IIS - Server vermeiden. In einigen Szenarien, z. B. Shared Hosting - Umgebungen, könnten Sie sich über nicht autorisierten Zugriff auf Quellcode auf dem IIS - Server Sorgen machen. (Bei einem Website - Projekt können Sie dieses Risiko vermeiden Vorkompilieren auf einem Entwicklungscomputer und Bereitstellen der generierten Assemblies anstelle des Quellcodes. In diesem Fall verlieren Sie jedoch einige der Vorteile von einfachen Websiteaktualisierungen.)
  7. Leistungsproblem mit der Website (Die erste Anforderung an die Website erfordert möglicherweise die Kompilierung der Site, was zu einer Verzögerung führen kann. Und wenn die Website auf einem IIS-Server mit wenig Arbeitsspeicher ausgeführt wird, einschließlich der gesamten Website in einer Eine einzelne Assembly benötigt möglicherweise mehr Speicher als für mehrere Assemblies erforderlich wäre.)



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.




Ich empfehle Ihnen, das Video Web Application Projects und Web Deployment Projects auf der ASP.NET-Website zu betrachten, das den Unterschied im Detail erklärt, es war sehr hilfreich für mich.

Übrigens, lassen Sie sich nicht durch den Titel verwirren, ein großer Teil des Videos erklärt den Unterschied zwischen Website-Projekten und Web-Anwendungsprojekten und warum Microsoft Web-Anwendungsprojekte in Visual Studio 2005 neu eingeführt hat (wie Sie wahrscheinlich schon wissen, es ursprünglich nur mit Website-Projekten ausgeliefert, dann wurden Web-Anwendungsprojekte in SP1 hinzugefügt). Ein tolles Video, das ich jedem empfehlen kann, der den Unterschied wissen möchte.




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.




Website und Projekt >> Website sind zwei verschiedene Methoden zum Erstellen von ASP.NET-Anwendungen mit Visual Studio. Einer ist ohne Projekt und ein anderer ist Projektumgebung. Unterschiede sind wie

  1. Die Lösungsdatei wird im selben Verzeichnis wie das Stammverzeichnis in der Projektumgebung gespeichert.
  2. Sie müssen Lösungs- und Projektdateien vor der Bereitstellung in der Projektumgebung entfernen.
  3. Das vollständige Stammverzeichnis wird in einer projektlosen Umgebung bereitgestellt.

Es gibt keinen grundlegenden Unterschied bei der Verwendung beider Ansätze. Wenn Sie Websites erstellen, die länger dauern, sollten Sie sich für die Projektumgebung entscheiden.




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.



Es hängt immer von den Anforderungen Ihres Kunden ab. ASP.NET enthält nur flexible Funktionen, die der Benutzer für die Sicherheit und einfache Wartung Ihrer Anwendung benötigt.

Sie können sich eine Webanwendung als Binärdatei vorstellen, die im ASP.NET-Framework ausgeführt wird. Und Websites als statische Webseite, auf der Sie Quellcode überprüfen und problemlos bereitstellen können.

Aber die Vorteile und Nachteile dieser beiden ASP.NET-Technologien kommen, was gut ist.




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.




WebSite: Es generiert App_code-Ordner automatisch und wenn Sie es auf dem Server veröffentlichen und danach, wenn Sie einige Änderungen in einer bestimmten Datei oder Seite vornehmen, müssen Sie nicht alle Dateien kompilieren.

Web Application Es generiert automatisch eine Lösungsdatei, die nicht generiert wird, und wenn Sie in einer Datei ändern, müssen Sie das vollständige Projekt kompilieren, um dessen Änderungen widerzuspiegeln.




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.




In einer Webanwendung können Sie die Ebenen der Projektfunktionalität erstellen und Abhängigkeiten zwischen ihnen erstellen, indem Sie sie in viele Projekte aufteilen. Dies können Sie jedoch nie auf einer Website tun.




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




Hier ist Web Supportive Application ein Beispiel für eine Website. Website und Web-Anwendung können beide dynamisch / statisch sein, es hängt von den Anforderungen ab, hier ist ein Beispiel, um das Arbeiten der Website und Web-Anwendung zu verstehen.




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.