Wenn ich ein neues ASP.NET-Projekt in Visual Studio starte, kann ich eine ASP.NET-Webanwendung 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 vorziehen?
Unterscheidet sich die Antwort je nach der von mir verwendeten Version von Visual Studio?
asp.net
.net
visual-studio
projects-and-solutions
Robert S.
quelle
quelle
Antworten:
Webseite:
Das Website- Projekt wird im laufenden Betrieb kompiliert. Sie haben am Ende viel mehr DLL-Dateien, was schmerzhaft sein kann. 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 den Code kompiliert wurde. Ein weiteres Problem kann beim Veröffentlichen sein.
Wenn Visual Studio nicht angewiesen wird, dieselben Namen ständig wiederzuverwenden, werden ständig neue Namen für die DLL-Dateien angezeigt, die von Seiten generiert werden. Dies kann dazu führen, dass mehrere nahe Kopien von DLL-Dateien mit demselben Klassennamen vorhanden sind, was zu zahlreichen Fehlern führt. Das Website-Projekt wurde mit Visual Studio 2005 eingeführt, hat sich jedoch als nicht beliebt erwiesen.
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 mit Visual Studio 2003 gelieferten Webprojekte funktioniert Kompilieren Sie die Anwendung zur Erstellungszeit in eine einzelne DLL-Datei. Um das Projekt zu aktualisieren, muss es neu kompiliert und die DLL-Datei veröffentlicht werden, damit Änderungen vorgenommen werden können.
Eine weitere nette Funktion des Webanwendungsprojekts ist, dass es viel einfacher ist, Dateien aus der Projektansicht auszuschließen. Im Website-Projekt wird jede von Ihnen ausgeschlossene Datei mit einem ausgeschlossenen Schlüsselwort im Dateinamen umbenannt. Im Webanwendungsprojekt verfolgt das Projekt nur, welche Dateien in die Projektansicht aufgenommen oder aus dieser ausgeschlossen werden sollen, ohne sie umzubenennen, was die Dinge viel aufgeräumter macht.
Referenz
Der Artikel ASP.NET 2.0 - Website gegen Webanwendungsprojekt gibt auch Gründe an, warum das eine und nicht das andere verwendet werden soll. Hier ist ein Auszug davon:
Webanwendungsprojekte im Vergleich zu Websiteprojekten (MSDN) erläutert die Unterschiede zwischen der Website und Webanwendungsprojekten. Außerdem wird die in Visual Studio durchzuführende Konfiguration erläutert.
quelle
Die Website stellen Sie auf einem ASP.NET-Webserver wie IIS bereit. Nur ein paar Dateien und Ordner. Eine Website enthält nichts, was Sie mit Visual Studio verbindet (es gibt keine Projektdatei). Die Codegenerierung und Kompilierung von Webseiten (wie .aspx, .ascx, .master) erfolgt dynamisch zur Laufzeit . Änderungen an diesen Dateien werden vom Framework erkannt und automatisch neu kompiliert. Sie können Code, den Sie zwischen Seiten teilen möchten, in den speziellen Ordner App_Code einfügen oder ihn vorkompilieren und die Assembly in den Ordner Bin legen.
Die Webanwendung ist ein spezielles Visual Studio-Projekt. Der Hauptunterschied zu Websites besteht darin, dass beim Erstellen des Projekts alle Codedateien in einer einzigen Assembly kompiliert werden, die im bin-Verzeichnis abgelegt wird. Sie stellen keine Codedateien auf dem Webserver bereit. Anstatt einen speziellen Ordner für gemeinsam genutzte Codedateien zu haben, können Sie diese wie in der Klassenbibliothek an einer beliebigen Stelle ablegen. Da Webanwendungen Dateien enthalten, die nicht bereitgestellt werden sollen, z. B. Projekt- und Codedateien, gibt es in Visual Studio den Befehl Veröffentlichen, mit dem eine Website an einem bestimmten Speicherort ausgegeben werden kann.
App_Code vs Bin
Das Bereitstellen von gemeinsam genutzten Codedateien ist im Allgemeinen eine schlechte Idee. Dies bedeutet jedoch nicht, dass Sie sich für eine Webanwendung entscheiden müssen. Sie können eine Website haben, die auf ein Klassenbibliotheksprojekt verweist, das den gesamten Code für die Website enthält. Webanwendungen 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 Codedateien in einer einzigen Assembly kompilieren lassen, einschließlich 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 immer wieder neu erstellen müssen, um die Änderungen zu sehen, während bei Websites Änderungen von der Laufzeit erkannt werden und Seiten / Steuerelemente automatisch neu kompiliert werden.
Die Laufzeitverwaltung der Codebehind-Assemblys ist für Sie weniger aufwendig, da Sie sich nicht darum kümmern müssen, Seiten / Steuerelementen eindeutige Namen zu geben oder sie in verschiedenen Namespaces zu organisieren.
Ich sage nicht, dass das Bereitstellen von Codedateien immer eine gute Idee ist (insbesondere nicht im Fall von gemeinsam genutzten Codedateien), aber Codebehind-Dateien sollten nur Code enthalten, der UI-spezifische Aufgaben, Handler für Verbindungsereignisse usw. ausführt. Ihre Anwendung sollte es sein geschichtet, so dass wichtiger Code immer im Ordner Bin landet. Wenn dies der Fall ist, sollte die Bereitstellung von Codebehind-Dateien nicht als schädlich angesehen werden.
Eine weitere Einschränkung von Webanwendungen besteht darin, dass Sie nur die Sprache des Projekts verwenden können. Auf Websites können einige Seiten in C #, einige in VB usw. vorhanden sein. Es ist keine spezielle Visual Studio-Unterstützung erforderlich. Das ist das Schöne an der Erweiterbarkeit des Build-Anbieters.
Außerdem erhalten Sie in Webanwendungen keine Fehlererkennung in Seiten / Steuerelementen, da der Compiler nur Ihre Codebehind-Klassen und nicht den Markup-Code kompiliert (in MVC können Sie dies mit der Option MvcBuildViews beheben), die zur Laufzeit kompiliert wird.
Visual Studio
Da Webanwendungen Visual Studio-Projekte sind, erhalten Sie einige Funktionen, die auf Websites nicht verfügbar sind. Sie können beispielsweise Build-Ereignisse verwenden, um eine Vielzahl von Aufgaben auszuführen, z. B. das Minimieren und / oder Kombinieren von Javascript-Dateien.
Eine weitere nette Funktion, die in Visual Studio 2010 eingeführt wurde, ist die Web.config-Transformation .
Dies ist auch auf Websites nicht verfügbar.Funktioniert jetzt mit Websites in VS 2013.Das Erstellen einer Webanwendung ist schneller als das Erstellen einer Website, insbesondere für große Websites. Dies liegt hauptsächlich daran, dass Webanwendungen den Markup-Code nicht kompilieren. Wenn Sie in MVC MvcBuildViews auf true setzen, wird der Markup-Code kompiliert und Sie erhalten eine Fehlererkennung, was sehr nützlich ist. Der Nachteil ist, dass jedes Mal, wenn Sie die Lösung erstellen, die gesamte Site erstellt wird. Dies kann langsam und ineffizient sein, insbesondere wenn Sie die Site nicht bearbeiten. Ich stelle fest, dass ich MvcBuildViews ein- und ausschalte (was das Entladen eines Projekts erfordert). Auf der anderen Seite können Sie bei Websites auswählen, ob Sie die Website als Teil der Lösung erstellen möchten oder nicht. Wenn Sie dies nicht möchten, ist die Erstellung der Lösung sehr schnell. Sie können jederzeit auf den Knoten Website klicken und Erstellen auswählen, wenn Sie Änderungen vorgenommen haben.
In einem MVC-Webanwendungsprojekt verfügen Sie über zusätzliche Befehle und Dialogfelder für allgemeine Aufgaben wie "Ansicht hinzufügen", "Zur Ansicht wechseln", "Controller hinzufügen" usw. Diese sind auf einer MVC-Website nicht verfügbar.
Wenn Sie IIS Express als Entwicklungsserver verwenden, können Sie auf Websites virtuelle Verzeichnisse hinzufügen. Diese Option ist in Webanwendungen nicht verfügbar.
NuGet Package Restore funktioniert nicht auf Websites. Sie müssen die in packages.config aufgelisteten Pakete manuell installierenDie Paketwiederherstellung funktioniert jetzt mit Websites , auf denen NuGet 2.7 gestartet wirdquelle
Website = Verwendung, wenn die Website von Grafikdesignern erstellt wird und die Programmierer nur eine oder zwei Seiten bearbeiten
Webanwendung = Verwendung, 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 erforderlich ist, da Projektdateien nicht aktualisiert werden müssen usw. Webanwendungen sind am besten geeignet, wenn das Team hauptsächlich Entwicklerstudio verwendet und ein hoher Code-Inhalt vorhanden ist.
(Einige Codierungsfehler werden zur Kompilierungszeit in Webanwendungen gefunden, die erst zur Laufzeit auf Websites gefunden werden.)
Warnung: Ich habe diese Antwort vor vielen Jahren geschrieben und Asp.net seitdem nicht mehr verwendet. Ich gehe davon aus, dass sich die Dinge jetzt weiterentwickelt haben.
quelle
Verwenden Sie kein Website-Projekt , es sei denn, Sie benötigen speziell ein dynamisch kompiliertes Projekt .
Warum? Weil ein Website-Projekt Sie an die Wand treibt, wenn Sie versuchen, Ihr Projekt zu ändern oder zu verstehen. Die statischen Suchfunktionen für die Eingabe (z. B. Verwendungszwecke finden, Refactor) in Visual Studio werden für jedes Projekt mit angemessener Größe ewig dauern. Weitere Informationen finden Sie in der Frage " Stapelüberlauf langsam" unter "Alle Referenzen suchen" in Visual Studio .
Ich kann wirklich nicht verstehen, warum sie Webanwendungen in Visual Studio 2005 für den Projekttyp Carbuncle-Website für schmerzverursachende, gesundheitsschädliche und produktive Carbuncle-Websites gelöscht haben.
quelle
In MSDN gibt es einen Artikel, der die Unterschiede beschreibt:
Vergleichen von Website-Projekten und Webanwendungsprojekten
Übrigens: Es gibt einige ähnliche Fragen zu diesem Thema, z.
quelle
Dies mag etwas offensichtlich klingen, aber ich denke, es wird missverstanden, da Visual Studio 2005 ursprünglich nur mit der Website geliefert wurde. Wenn sich Ihr Projekt mit einer Website befasst, die ziemlich begrenzt ist und nicht viel logische oder physische Trennung aufweist, ist die Website in Ordnung. Wenn es sich jedoch wirklich um eine Webanwendung mit verschiedenen Modulen handelt, in denen viele Benutzer Daten hinzufügen und aktualisieren, ist die Webanwendung besser geeignet.
Der größte Vorteil des Website-Modells ist, dass alles in diesem
app_code
Abschnitt dynamisch kompiliert wird. Sie können C # -Datei-Updates ohne vollständige erneute Bereitstellung durchführen. Dies bringt jedoch ein großes Opfer mit sich. Unter der Decke passieren viele Dinge, die schwer zu kontrollieren sind. Namespaces sind schwer zu kontrollieren und die spezifische DLL-Nutzung wird standardmäßig für alles unter dem Fenster ausgeblendet,app_code
da alles dynamisch kompiliert wird.Das Webanwendungsmodell verfügt nicht über eine dynamische Kompilierung, aber Sie erhalten die Kontrolle über die von mir erwähnten Dinge.
Wenn Sie eine n-Tier-Entwicklung durchführen, empfehle ich das Webanwendungsmodell. Wenn Sie eine eingeschränkte Website oder eine schnelle und fehlerhafte Implementierung durchführen, kann das Website-Modell Vorteile haben.
Eine detailliertere Analyse finden Sie in:
quelle
Aus dem MCTS Self-Paced Training Kit Prüfung 70-515 Buch:
quelle
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.
In einer Anwendung werden die Daten in der Regel in einer Datenbank gespeichert, und die Seiten und der Code ändern sich selten. In diesem Fall ist es besser, eine Webanwendung zu haben, in der die Bereitstellung von Assemblys viel kontrollierter ist und Unit-Tests besser unterstützt.
quelle
Project structure
Es gibt auch einen Unterschied in der Struktur des Projekts. In der Webanwendung haben Sie eine Projektdatei, wie Sie sie in einer normalen Anwendung hatten. Auf der Website gibt es keine herkömmliche Projektdatei. Sie haben lediglich eine Lösungsdatei. Alle Referenzen und Einstellungen werden in der Datei web.config gespeichert.@Page directive
In der @ Page-Direktive gibt es ein anderes Attribut für die Datei, die die dieser Seite zugeordnete Klasse enthält. In der Webanwendung ist es Standard "CodeBehind", auf der Website verwenden Sie "CodeFile". Sie können dies in den folgenden Beispielen sehen:Internetanwendung:
Webseite:
quelle
Ja, Webanwendungen sind viel besser als Websites, da Webanwendungen uns Freiheit geben:
Mehrere Projekte unter einem Dach haben und Projektabhängigkeiten zwischen ihnen herstellen. ZB für PCS können wir folgende innerhalb der Webanwendung haben-
Ausführen von Komponententests für Code in den Klassendateien, die ASP.NET-Seiten zugeordnet sind
quelle
Einer der Hauptunterschiede besteht darin, dass Websites dynamisch kompiliert und On-the-Fly-Assemblys erstellt werden. Webanwendungen werden zu einer großen Baugruppe kompiliert.
Die Unterscheidung zwischen beiden wurde in Visual Studio 2008 aufgehoben.
quelle
Anwendungen werden normalerweise vor der Bereitstellung kompiliert, wenn die Website das Verzeichnis app_code verwendet. Wenn sich im App-Code-Ordner etwas ändert, kompiliert der Server den Code neu. 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 erfolgt und die ersten Startzeiten kürzer sind.
quelle
Ich empfehle Ihnen, das Video Webanwendungsprojekte und Webbereitstellungsprojekte auf der ASP.NET-Website anzusehen, in dem der Unterschied ausführlich erläutert wird. Es war für mich sehr hilfreich.
Übrigens, lassen Sie sich nicht vom Titel verwirren. Ein großer Teil des Videos erklärt den Unterschied zwischen Website-Projekten und Webanwendungsprojekten und warum Microsoft Webanwendungsprojekte in Visual Studio 2005 wieder eingeführt hat (wie Sie wahrscheinlich bereits wissen) ursprünglich nur mit Website-Projekten ausgeliefert, dann wurden Webanwendungsprojekte in SP1 hinzugefügt). Ein großartiges Video, das ich jedem empfehlen kann, der den Unterschied wissen möchte.
quelle
Eine "Website" hat ihren Code in einem speziellen App_Code-Verzeichnis und wird zur Laufzeit in mehrere DLLs (Assemblys) kompiliert. Eine "Webanwendung" wird in einer einzigen DLL vorkompiliert.
quelle
Website und Project >> Website sind zwei verschiedene Methoden zum Erstellen einer ASP.NET-Anwendung mit Visual Studio. Eines ist projektlos und ein anderes ist die Projektumgebung. Unterschiede sind wie
Es gibt keinen großen grundsätzlichen Unterschied bei der Verwendung beider Ansätze. Wenn Sie jedoch eine Website erstellen, die länger dauert, entscheiden Sie sich für die Projektumgebung.
quelle
Webanwendungsprojektmodell
Website-Projektmodell
quelle
Dies hängt immer von den Anforderungen Ihres Kunden ab. ASP.NET enthält lediglich flexible Funktionen, die der Benutzer für die Sicherheit und einfache Wartung Ihrer Anwendung benötigt.
Sie können sich eine Webanwendung als eine Binärdatei vorstellen, die im ASP.NET-Framework ausgeführt wird. Und Websites als statische Webseite, auf der Sie den Quellcode überprüfen und problemlos bereitstellen können.
Die Vor- und Nachteile dieser beiden ASP.NET-Technologien sind jedoch gut.
quelle
Websites - Es wird keine Lösungsdatei erstellt. Wenn wir Websites erstellen möchten, ist kein Visual Studio erforderlich.
Webanwendung - Eine Lösungsdatei wird erstellt. Wenn wir eine Webanwendung erstellen möchten, sollte das Visual Studio benötigt werden. Es wird eine einzelne
.dll
Datei im Ordner bin erstellt.quelle
In Webanwendungsprojekten benötigt Visual Studio zusätzliche Designer-Dateien für Seiten und Benutzersteuerelemente. Website-Projekte erfordern diesen Overhead nicht. Das Markup selbst wird als Design interpretiert.
quelle
WebSite: Der Ordner app_code wird automatisch generiert. Wenn Sie ihn auf dem Server veröffentlichen und danach einige Änderungen an einer bestimmten Datei oder Seite vornehmen, müssen Sie nicht alle Dateien kompilieren.
Webanwendung Es wird automatisch eine Lösungsdatei generiert, die von der Website nicht generiert wird. Wenn Sie eine Datei ändern, müssen Sie das vollständige Projekt kompilieren, um die Änderungen widerzuspiegeln.
quelle
In einer Webanwendung können Sie die Ebenen der Funktionalität Ihres Projekts erstellen und Abhängigkeiten zwischen ihnen erstellen, indem Sie sie in viele Projekte aufteilen. Dies ist jedoch auf einer Website niemals möglich.
quelle
Auf jeden Fall Webanwendung, einzelne DLL-Datei und einfach zu pflegen. Eine Website ist jedoch flexibler. Sie können die Aspx-Datei unterwegs bearbeiten.
quelle
Webanwendungen benötigen mehr Speicher, vermutlich weil Sie keine andere Wahl haben, als in einer einzigen Assembly zu kompilieren. Ich habe gerade eine große Legacy-Site in eine Webanwendung konvertiert und habe Probleme mit dem Speichermangel, beide zur Kompilierungszeit mit der folgenden Fehlermeldung:
Fehler und zur Laufzeit mit dieser Fehlermeldung wie folgt:
Meine Empfehlung für die Konvertierung größerer Websites auf speicherbeschränkter Legacy-Hardware lautet, die Option zum Zurücksetzen auf das Website-Modell zu wählen. Auch nach einem anfänglichen Erfolg kann sich später ein Problem ergeben.
quelle
Hier ist die Web Supportive Application ein Beispiel für eine Website. Website und Webanwendung können beide dynamisch / statisch sein. Dies hängt von den Anforderungen ab. Hier ist ein Beispiel, um die Funktionsweise von Websites und Webanwendungen zu verstehen.
quelle
Um einige der obigen Antworten zusammenzufassen:
Flexibilität , können Sie Live-Änderungen an einer Webseite vornehmen?
Website : Möglich. Pro: kurzfristige Vorteile. Con: Langzeitrisiko des Projektchaos.
Web App : Con: nicht möglich. Bearbeiten Sie eine Seite, archivieren Sie die Änderungen an der Quellcodeverwaltung und erstellen und implementieren Sie die gesamte Site. Pro: ein Qualitätsprojekt pflegen.
Entwicklungsprobleme
Website : Einfache Projektstruktur ohne .csproj-Datei. Zwei .aspx-Seiten können ohne Konflikte denselben Klassennamen haben. Zufälliger Projektverzeichnisname, der zu Erstellungsfehlern führt, z. B. warum .net Framework mit seiner eigenen generierten Datei in Konflikt steht und warum .net Framework mit seiner eigenen generierten Datei in Konflikt steht . Pro: Einfach (simpel). Con: unberechenbar.
Web App : Projektstruktur ähnlich dem WebForms-Projekt mit einer .csproj-Datei. Klassennamen von Asp-Seiten müssen eindeutig sein. Pro: Einfach (klug). Con: keine, weil eine Web-App immer noch einfach ist.
quelle