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

848

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?

Robert S.
quelle
6
Ein vollständiger und neuerer (für 4.5) Vergleich und eine Erklärung finden Sie hier bei MSDN: Webanwendungsprojekte versus Website-Projekte in Visual Studio
Gustav

Antworten:

556

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:

  • Sie müssen große Visual Studio .NET 2003-Anwendungen auf VS 2005 migrieren? Verwenden Sie das Webanwendungsprojekt.
  • Sie möchten ein Verzeichnis als Webprojekt öffnen und bearbeiten, ohne eine Projektdatei zu erstellen? Verwenden Sie das Website-Projekt.
  • Sie müssen während der Kompilierung Schritte vor und nach dem Erstellen 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 die dynamische Kompilierung und das Bearbeiten von Seiten, ohne auf jeder Seitenansicht die gesamte Site zu erstellen? Verwenden Sie das Website-Projekt.
  • Sie bevorzugen ein einseitiges Codemodell gegenüber einem Code-Behind-Modell? Verwenden Sie das Website-Projekt.

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.

Andreas Grech
quelle
5
Sie können weiterhin Ihre gesamte Site mit der dateibasierten Website zu einer DLL kompilieren.
dtc
31
So wie ich es mir vorstelle. Wenn Sie eine Anwendung programmieren, die zufällig HTML als Benutzeroberfläche verwendet, verwenden Sie die Webanwendung. Wenn Sie eine Website haben, die auf einigen Seiten etwas Asp.net benötigt, verwenden Sie das Website-Projekt.
Ian Ringrose
35
Tatsächlich waren Webanwendungsprojekte genau der ursprüngliche ASP.NET-Projekttyp. Sie sind nicht "wie" die Projekte, die wir in Visual Studio 2003 hatten. Sie wurden nicht als Add-In erstellt. Visual Studio 2005 SP1 hat einfach wiederhergestellt, was Visual Studio 2005 RTM versehentlich entfernt hat.
John Saunders
1
Sie können die WebApplication-Ausgabe in einem WebDeployment-Projekt verwenden. Sie können die WebSite-Ausgabe nicht in einem WebDeployment-Projekt verwenden. Wenn Sie ein Bereitstellungsprojekt erstellen möchten, bleiben Sie bei WebApplication. Für die Entwicklung ist WebSite jedoch bequemer. Die Konvertierung ist jedoch nicht immer problemlos. Beginnen Sie daher sofort mit WebApplication.
Stefan Steiger
8
@xarzu: Website- "Projekte" haben keine .csproj- oder .vbproj-Datei. Sie sind keine wirklichen Projekte - sie sind nur Ordner voller Dateien.
John Saunders
171

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 wird

Max Toro
quelle
43
Da die Programmierer die Anwendung schreiben, wird die Anwendung dann erstellt. Das Testteam testet die Anwendung auf dem Testsystem. Anschließend installiert der Kunde die Anwendungen. Das LETZTE, was Sie wollen, ist, dass jemand Live-Änderungen vornimmt!
Ian Ringrose
12
Für mich ist die Wahl die beste, auf Websites können Sie immer von einer vorkompilierten Basisklasse erben, wenn Sie möchten. Es gibt viele Sprachen / Frameworks (z. B. PHP), in denen die Leute an die Idee gewöhnt sind, Quellcode bereitzustellen. Das bedeutet nicht, dass dies keine "ernsthaften" Anwendungen sind.
Max Toro
6
"Eigentlich verwalten Sie diese DLLs nicht, [...] Sie müssen nicht einmal wissen, dass sie existieren. Kein Problem." - Bis das Framework verwirrt wird, die alten Versionen nicht korrekt bereinigt werden und Kompilierungsausnahmen mit widersprüchlichen Namen auf der gesamten Site ausgelöst werden ... Sie können die Fehlererkennung des Markups mithilfe eines WebDeployment-Projekts hinzufügen. Ich bin mir auch nicht sicher, ob Sie in Ihrem letzten Punkt "Mit Websites können Sie IIS als Server verwenden" dies auch mit einer Webanwendung tun können - und ich habe Projekte wie dieses, bei denen das Projekt Teil einer größeren Webanwendung ist.
Zhaph - Ben Duguid
3
Das Bereitstellen einer Website muss nicht immer auf einem Live-Server erfolgen. Entwicklungsiterationen sollten in einer perfekten Welt auf einem Spiegel der Live-Umgebung getestet werden. Da Web Apps nicht in der Lage sind, schnelle Codeänderungen an einer Site vorzunehmen, die auf einem Development IIS-Server ausgeführt wird (dh nicht mit der lokalen VS-Instanz ausgeführt wird), ist es ein großes Problem, schnelle kleine Lösungen zu testen. Dies geschieht ständig in Systemen, in denen Sie nicht dieselben Bedingungen auf Ihrem lokalen Computer replizieren können.
NikoRoberts
4
"Dies kann während der Entwicklung ein echtes Problem sein, da Sie immer wieder neu aufbauen müssen, um die Änderungen zu sehen." ein Umbau in diesen Tagen.
Darren
75

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.

Ian Ringrose
quelle
40

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.

ninj
quelle
30

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.

M4N
quelle
Ich denke, die Antwort darüber, ob ich Codefile oder Codebehind im Markup verwenden soll, ist mit der Antwort weg, die von SO gelöscht wurde ...
Frenchone
Also für diejenigen, die sich fragen: Webanwendung = gut strukturierte Lösung = Codebehind in Markup VS Website = Bündel von Dateien = Codefile in Markup
Französisch
22

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_codeAbschnitt 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_codeda 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:

Daniel Auger
quelle
3
> Der größte Vorteil des Website-Modells ist, dass alles im Abschnitt app_code dynamisch kompiliert wird. Dies hat auch einen großen Nachteil. Meine Website wird mit webhost4life gehostet, die billig, aber reich an Funktionen sind. Der Nachteil ist, dass sie den Arbeitsprozess sehr häufig (15 Minuten?) Wiederverwenden, was bedeutet, dass der nächste Benutzer beim erneuten Kompilieren der Anwendung ein sehr langsames Ausblenden der ersten Seite hat.
Rob Nicholson
19

Aus dem MCTS Self-Paced Training Kit Prüfung 70-515 Buch:

Mit Webanwendung (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 zu beenden.
  5. Sie können Abhängigkeiten zwischen mehreren Webprojekten herstellen.
  6. Sie müssen die Anwendung vor der Bereitstellung kompilieren, damit Sie eine Seite nicht testen können, wenn eine andere Seite nicht kompiliert werden kann.
  7. Sie müssen den Quellcode nicht auf dem Server speichern.
  8. Sie können den Namen und die Version der Baugruppe steuern.
  9. Sie können einzelne Dateien nach der Bereitstellung nicht bearbeiten, ohne sie neu zu kompilieren.
YuMei
quelle
# 4 ist falsch. "Bearbeiten und fortfahren" kann mit einigen Einschränkungen aktiviert werden. Vielleicht stimmte dies im Jahr 2011. # 9 sollte sagen "Sie können einzelne Quellcodedateien nicht bearbeiten, ohne sie neu zu kompilieren". Sie können ASPX, JS, CSS usw. bearbeiten, ohne sie neu zu kompilieren.
John Saunders
# 4 hat einen anderen Winkel. Wenn Sie eine Website über Datei> Öffnen> Website öffnen und zum Dateisystemordner für die Website navigieren , können Sie Klassenmodule und Codebehind (zumindest in vb.net) bearbeiten , anstatt die Site durch Auswahl der Lösung im Startfenster zu öffnen ) ohne das Debuggen zu stoppen. Sie werden die Änderungen erst sehen, wenn Sie sie neu erstellen. Oft ist es jedoch hilfreich, das Seitenverhalten zu beobachten, während Sie den Code ändern. Der Nachteil ist, dass Sie alles verlieren, was in die Lösung einfließt: Haltepunkte, geöffnete Dateien, Lesezeichen usw. Und manchmal müssen Sie die sln / sou-Dateien löschen.
Wayfarer
16

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.

AnthonyWJones
quelle
16

Compilation Erstens gibt es einen Unterschied in der Zusammenstellung. Die Website ist nicht auf dem Server vorkompiliert, sondern in einer Datei. Dies kann von Vorteil sein, da Sie, wenn Sie etwas auf Ihrer Website ändern möchten, einfach eine bestimmte Datei vom Server herunterladen, ändern und diese Datei wieder auf den Server hochladen können. Alles würde gut funktionieren. In der Webanwendung können Sie dies nicht tun, da alles vorkompiliert ist und Sie nur eine DLL haben. Wenn Sie etwas in einer Datei Ihres Projekts ändern, müssen Sie alles erneut kompilieren. Wenn Sie also die Möglichkeit haben möchten, einige Dateien auf der Server-Website zu ändern, ist dies die bessere Lösung für Sie. Außerdem können viele Entwickler an einer Website arbeiten. Wenn Sie jedoch nicht möchten, dass Ihr Code auf dem Server verfügbar ist, sollten Sie lieber Webanwendung wählen.

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:

<%@ 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 noch einen weiteren Unterschied - wie Namespaces erstellt werden. Im Webanwendungs-Namespace ist einfach ein Name des Projekts. In der Website gibt es einen Standard-Namespace-ASP für dynamisch kompilierte Seiten.

Bearbeiten und fortfahren - In der Webanwendung ist die Option Bearbeiten und fortfahren verfügbar (um sie zu aktivieren, müssen Sie zum Menü Extras gehen, auf Optionen klicken und dann unter Debuggen Bearbeiten und fortfahren suchen). Diese Funktion funktioniert in Web Site.ASP.NET MVC nicht, wenn Sie Webanwendungen mit verwenden möchten

ASP.NET MVC (Model View Controller) Die beste und Standardoption ist Webanwendung. Obwohl es möglich ist, MVC auf einer Website zu verwenden, wird dies nicht empfohlen.

Zusammenfassung - Der wichtigste Unterschied zwischen ASP.NET-Webanwendung und 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. Wenn Sie jedoch ein kleineres Projekt ausführen, können Sie auch die Webanwendung verwenden.

Himanshu
quelle
Bei einem großen Projekt, bei dem mehr als eine Person es ändert, verwenden Sie die Quellcodeverwaltung. Dies ist also kein Grund, Website- "Projekte" zu verwenden.
John Saunders
+1 für die Unterscheidung zwischen Codebehind (Webapp) und Codefile (Website) in der Seitenanweisung. Dies ist eine Genauigkeit, die in der ausgewählten Antwort fehlt.
Französisch
11

Ja, Webanwendungen sind viel besser als Websites, da Webanwendungen uns Freiheit geben:

  1. Mehrere Projekte unter einem Dach haben und Projektabhängigkeiten zwischen ihnen herstellen. ZB für PCS können wir folgende innerhalb der Webanwendung haben-

    • Webportale
    • Notification Controller (zum Senden von E-Mails)
    • Geschäftsschicht
    • Datenzugriffsschicht
    • Ausnahmemanager
    • Server-Dienstprogramm
    • WCF-Dienste (gemeinsam für alle Plattformen)
    • Listenpunkt
  2. Ausführen von Komponententests für Code in den Klassendateien, die ASP.NET-Seiten zugeordnet sind

  3. Verweisen auf die Klassen, die Seiten und Benutzersteuerelementen aus eigenständigen Klassen zugeordnet sind
  4. So erstellen Sie eine einzelne Baugruppe für die gesamte Site
  5. Kontrolle über den Assemblynamen und die Versionsnummer, die für die Site generiert werden
  6. Um zu vermeiden, dass Quellcode auf einem Produktionsserver abgelegt wird. (Sie können die Bereitstellung von Quellcode auf dem IIS-Server vermeiden. In einigen Szenarien, z. B. in gemeinsam genutzten Hosting-Umgebungen, sind Sie möglicherweise besorgt über den nicht autorisierten Zugriff auf den Quellcode auf dem IIS-Server. (Bei einem Website-Projekt können Sie dieses Risiko vermeiden, indem Sie Vorkompilieren auf einem Entwicklungscomputer und Bereitstellen der generierten Assemblys anstelle des Quellcodes. In diesem Fall verlieren Sie jedoch einige der Vorteile einfacher Site-Updates.)
  7. Leistungsproblem mit der Website (Bei der ersten Anforderung an die Website muss die Website möglicherweise kompiliert werden, was zu einer Verzögerung führen kann. Wenn die Website auf einem IIS-Server mit wenig Arbeitsspeicher ausgeführt wird, einschließlich der gesamten Website in a Eine einzelne Baugruppe benötigt möglicherweise mehr Speicher als für mehrere Baugruppen erforderlich wäre.)
Nilesh Rathod
quelle
11

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.

Sam Cogan
quelle
4
"Die Unterscheidung zwischen den beiden wurde in vs2008 aufgehoben" - nicht sicher, was Sie dort meinen - sie sind immer noch unterschiedliche Projekttypen in VS2008, verhalten sich unterschiedlich und werden über verschiedene Menüoptionen erstellt - zumindest sind beide standardmäßig verfügbar in VS2008.
Zhaph - Ben Duguid
9

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.

Daisy Moon
quelle
Das ist teilweise richtig, Sie können Seiten auf der Website vorkompilieren, wenn Sie möchten
Amr H. Abd Elmajeed
8

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.

Waleed Eissa
quelle
Das Video ist jetzt bei: asp.net/web-forms/videos/vs-2005/…
Bob Reynolds
7

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.

md adilahmed
quelle
5

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

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

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.

Chaturvedi Dewashish
quelle
1
Die Lösungsdatei muss sich nicht im selben Ordner befinden. Außerdem entfernt der Standardveröffentlichungsmechanismus alle Artefakte, die sich nicht auf der Zielsite befinden sollten. Beispielsweise werden Codebehind-Dateien nicht bereitgestellt.
John Saunders
5

Webanwendungsprojektmodell

  • Bietet dieselbe Webprojektsemantik wie Visual Studio .NET-Webprojekte. Hat eine Projektdatei (Struktur basierend auf Projektdateien). Modell erstellen - Der gesamte Code im Projekt wird in einer einzigen Assembly kompiliert. Unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server. Unterstützt alle Funktionen von Visual Studio 2005 (Refactoring, Generika usw.) und von ASP.NET (Masterseiten, Mitgliedschaft und Anmeldung, Site-Navigation, Themen usw.). Die Verwendung von FrontPage Server Extensions (FPSE) ist nicht mehr erforderlich.

Website-Projektmodell

  • Keine Projektdatei (basierend auf dem Dateisystem).
  • Neues Kompilierungsmodell.
  • Dynamisches Kompilieren und Bearbeiten von Seiten, ohne bei jeder Seitenansicht die gesamte Site zu erstellen.
  • Unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server.
  • Jede Seite hat eine eigene Baugruppe.
  • Unterschiedliches Codemodell.
user1855471
quelle
5

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.

jovenb
quelle
4

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 .dllDatei im Ordner bin erstellt.

Nagaraj P.
quelle
2
-1 Sie haben tatsächlich eine Lösungsdatei, wenn Sie ein Website-Projekt über Visual Studio erstellen. Sie haben keine Projektdatei.
Darren
+1 sicher, Sie können eine Lösungsdatei erstellen, aber diese Datei ist größtenteils leer, so dass es nur ein Ärger ist (VS fragt, wo die Datei beim Beenden gespeichert werden soll) und nicht etwas
Nützliches
3

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.

Goodmedalist
quelle
3

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.

Mukesh Kumar
quelle
"Vollständiges Projekt kompilieren" bedeutet nicht, jede Datei im Projekt zu kompilieren. Nicht geänderte Quellcodedateien werden nicht neu kompiliert.
John Saunders
3

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.

Imran Chaudhary
quelle
3

Auf jeden Fall Webanwendung, einzelne DLL-Datei und einfach zu pflegen. Eine Website ist jedoch flexibler. Sie können die Aspx-Datei unterwegs bearbeiten.

Gadasadox
quelle
Sie können die Aspx-Datei auch in einem Webanwendungsprojekt bearbeiten.
John Saunders
3

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:

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

Fehler und zur Laufzeit mit dieser Fehlermeldung wie folgt:

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 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.

cdonner
quelle
Dies scheint keine Ausnahme bei der Kompilierung zu sein.
John Saunders
1

Hier ist die Web Supportive Application ein Beispiel für eine Website.

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
Dies gilt nicht in asp.net. Bei der Unterscheidung zwischen Website und Webanwendung (in der asp.net-Terminologie) geht es eher darum, wie die Dateien organisiert (als gut organisierte Lösung oder als Bündel von Dateien) und kompiliert werden ("JIT" vs. statisch). In beiden Fällen ist das "Programm" hauptsächlich serverseitig.
Französisch
0

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.

Roland
quelle