Unterschiede zwischen dem Kompilieren einer Website und einer Webanwendung

Es gibt viele verschiedene ASP.NET-Module, die auf verschiedenen Plattformen basieren, z. B. Web Forms, Webseiten, Model-View-Controller (MVC) und das neueste - Core. In diesem Artikel möchte ich einige Unterschiede zwischen dem Kompilieren einer ASP.NET-Website und einer ASP.NET-Webanwendung untersuchen.



Zusammenstellung einer Website (Abb. 1) und einer Webanwendung (Abb. 2).



Abb. 1: ASP.NET-Website und Unterscheidung zwischen ASP.NET-Website und ASP.NET-Webanwendung



Abb. 2: ASP.NET-Webanwendung und Unterscheidung zwischen ASP.NET-Website und ASP.NET-Webanwendung

In diesem Artikel geht es nicht um die interne Struktur von ASP.NET-Projekten, sondern um die Erfahrungen, die ich bei der Arbeit an der Azure App Service-Plattform gesammelt habe. Das interne Gerät ist hier bereits dokumentiert - "Vorkompilieren Ihrer Website (C #)" ("Vorkompilieren einer Website in C #"). Sie müssen den Unterschied zwischen automatischer und expliziter Kompilierung verstehen. Wenn Sie mit einer ASP.NET-Website arbeiten, sollten Sie ernsthaft eine Vorkompilierung mit aspnet_compiler.exe in Betracht ziehen, wie unter Gewusst wie: Vorkompilieren von ASP.NET-Websites (Vorkompilieren von Websites) beschrieben ASP.NET ").

Im Folgenden finden Sie eine Reihe von Veröffentlichungen, mit denen Sie Ihren Horizont zu diesem Thema erweitern und andere Themen untersuchen können:

• "Warum wird meine ASP.NET-Anwendung recycelt und neu gestartet?" ("Warum wird die ASP.NET-Anwendung neu kompiliert und neu geladen?")
• "Muss WinDbg-Befehle verwenden, muss sie kennen, meine am häufigsten verwendeten" ("WinDbg-Befehle, die ich kennen und anwenden muss und die ich am häufigsten verwende")
• Übung 28: Die Auswirkungen von Debug = true („Lektion 28: Die Auswirkungen von Debug = true“)
• "Debug = True"
• Alle meine ASP.NET-Artikel

Wo hat alles angefangen? Ich wollte überprüfen, ob ich den Prozess des Kompilierens von ASP.NET-Modulen in Assemblys richtig verstanden habe, und entschied mich, dies in der Azure App Service-Umgebung zu tun. Ich hatte bereits ein Konzept über temporäre ASP.NET-Dateien, über das Kompilieren von ASPX-Dateien zu einer DLL-Assembly und darüber, wo sie auf einem eigenständigen Server gespeichert wurden. Ich war mir sicher, dass auf der App Service-Plattform die ersten beiden Punkte auf ähnliche Weise implementiert wurden, aber ich bezweifelte den dritten - nämlich, wo die kompilierten Assemblys gespeichert sind. Also habe ich einen Code geschrieben, um das herauszufinden.

public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } }      () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater> 

Dann habe ich diesen Code auf der App Service-Plattform veröffentlicht.

Als ich zum ersten Mal auf die Website zugegriffen habe, habe ich das in Abb. 1 gezeigte Ergebnis erhalten. 3 (ursprünglich drei Seiten im Stammverzeichnis meiner ASP.NET-Website)



Abb. 3: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Ich habe die Website neu gestartet und die Binärdateien zu einer neuen Assembly kompiliert (Abbildung 4). Dies war ziemlich unerwartet, da ich nur neu gestartet und keine Bereitstellungen oder Änderungen vorgenommen habe.



Abb. 4: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Ich habe in KUDU das Assembly-Verzeichnis durchsucht und es nicht gefunden. es war sehr seltsam.

Nachdem ich auf die Links "Eine andere Seite" und "Und eine andere Seite" geklickt hatte, wurden alle meine Seiten zu einer Assembly zusammengefasst, und ich war sehr überrascht, dies zu finden, da debug = true in meiner Datei "web.config" festgelegt wurde.

Ich musste die Antworten auf die folgenden Fragen herausfinden:

1. Warum wurde meine Anwendung nach dem Neustart neu kompiliert, obwohl ich keine Bereitstellungs- oder Konfigurationsänderungen vorgenommen habe?
2. Warum habe ich die Assembly nicht in KUDU gefunden, obwohl mein Quellcode korrekt war?
3. Warum wurde meine Anwendung in einer einzigen Assembly kompiliert, obwohl debug = true in der Datei web.config festgelegt wurde?

Die Antwort auf die erste Frage war, dass ich mir tatsächlich die KUDU-Versammlung ansah, nicht die, die für den App Service zusammengestellt wurde. Schauen Sie sich Abbildung 2 im Artikel „Erstellen eines Speicherauszugs für Ihre langsam arbeitende Web-App“ an. Dies zeigt, dass KUDU in einem anderen Prozess als der App Service ausgeführt wird. Daher hat sich KUDU beim Erstellen der Instanz neu kompiliert und war nicht meine Instanz des App Service.

Ich habe auch die zweite Frage anhand der Informationen sortiert, die ich zur ersten Frage erhalten habe. Ich werde Details zur Konfiguration von Dateien auf der App Service-Plattform weglassen und sagen, dass ich meine ASP.NET-Website-Assemblys auf dieser Plattform anzeigen konnte: Dazu habe ich WEBSITE_DISABLE_SCM_SEPARATION auf true gesetzt (siehe Abbildung 5). Tun Sie dies nur zum Testen und (oder) Debuggen und für nichts weiter. Ich empfehle nicht, mehrere Seiten einer Website einem einzelnen Prozess in App Service zuzuordnen. Setzen Sie diesen Wert nach Abschluss des Debuggens zurück und trennen Sie die Prozesse erneut.



Abb. 5: Kompilieren der ASP.NET-Website im Azure App Service; Ich kann keine temporären ASP.NET-Dateien auf KUDU finden

Die Antwort auf die dritte Frage lautete: Wenn die Datei Web.Debug.config vorhanden ist, wird das Attribut debug = true während des Bereitstellungsprozesses gelöscht.

 <compilation xdt:Transform="RemoveAttributes(debug)" /> 

Ich habe hier , hier und hier über XDT-Dateien geschrieben, aber in diesem Fall musste ich ein wenig nachdenken, um ihre Bedeutung zu verstehen (sich daran zu erinnern, sie zu erkennen).

Nachdem ich WEBSITE_DISABLE_SCM_SEPARATION auf true gesetzt hatte, machte ich einen Stopp und Start, mit anderen Worten einen Kaltstart ... und sah, dass sowohl SCM / KUDU als auch meine Website tatsächlich im selben Prozess gestartet wurden (Abb. 6.)



Abb. 6: Kompilieren der ASP.NET-Website im Azure App Service; Ich kann keine temporären ASP.NET-Dateien auf KUDU finden

Die Veröffentlichung und Kompilierung von default.aspx wird initiiert, der Assemblyname bleibt nach allen Anfragen unverändert (Abb. 7).



Abb. 7: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Um dies zu überprüfen, habe ich einen Speicherauszug des Prozessspeichers erstellt, einen Speicherauszug des Moduls erstellt und analysiert. Ehrlich gesagt war ich immer noch verwirrt über das Ergebnis der Assembly, da ich den Parameter debug = true erst nach Abschluss aller Tests herausgefunden habe. Manchmal schreibe ich Artikel in der falschen Reihenfolge, in der Ereignisse folgen. Verwirrt beschloss ich, die Batch-Kompilierung zu testen. Lesen Sie hier darüber : "Kompilierungselement (ASP.NET-Einstellungsschema)" ("Kompilierungselement - ASP.NET-Webparameterschema"). Ich hatte erwartet, dass eine Baugruppe pro Seite kompiliert wird, daher war das Ergebnis (siehe Abbildung 8) eine völlige Überraschung.



Abb. 8: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Ich habe erwartet, dass eine Assembly pro Seite angezeigt wird, da ich dachte, ich arbeite mit dem Parameter debug = true. Beim Lesen über die Stapelkompilierung wurde mir klar, dass alle Seiten in der Assembly kompiliert werden, die in einem bestimmten Verzeichnis enthalten ist. Also habe ich zwei Verzeichnisse erstellt und die ASPX-Dateien in jedes von ihnen eingefügt. Die PID änderte sich nicht, so dass es keinen „Kaltstart“ gab (Abb. 9).



Abb. 9: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Die Site wurde jedoch tatsächlich in eine andere Binärdatei neu kompiliert, blieb jedoch im selben Verzeichnis (Pfad) (Abb. 10).



Abb. 10: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Ich habe den Speicher gelöscht, um die Richtigkeit meiner Schlussfolgerungen vollständig zu überprüfen. Und als ich mich dem Stammverzeichnis der Site zuwandte und sah, dass alle Seiten im Verzeichnis kompiliert wurden, stellte ich fest, dass meine Hypothese zur Stapelkompilierung bestätigt wurde (Abb. 11).



Abb. 11: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Ich folgte dem Link „Verzeichnis 1“ und sah eine weitere Baugruppe (Abb. 12).



Abb. 12: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Ich habe den Speicher erneut entleert, den Modul-Dump entfernt und festgestellt, dass er wirklich der Seite „Verzeichnis 1“ entspricht (Abb. 13).



Abb. 13: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Dasselbe habe ich für die Seite Verzeichnis 2 getan (Abb. 14 und 15).



Abb. 14: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform



Abb. 15: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Ich hatte auch die Möglichkeit, selbst zu den Versammlungen in SCM / KUDU zu gehen (Abb. 16).



Abb. 16: Kompilieren einer ASP.NET-Website auf der Azure App Service-Plattform

Sobald ich das Problem mit dem Parameter debug = true herausgefunden hatte, passte alles zusammen und es war eine gute Lernerfahrung. Ich hoffe, Sie finden meinen Artikel hilfreich.

Nützliche Ressourcen

Handbuch zur Cloud-Anwendungsarchitektur

Verfolgen Sie einen strukturierten Ansatz für die Entwicklung von Cloud-Anwendungen. In diesem 300-seitigen E-Book zur Cloud-Computing-Architektur werden Richtlinien für Architektur, Entwicklung und Implementierung erläutert, die unabhängig von der gewählten Cloud-Plattform gelten. Diese Anleitung enthält Schritte zu:

• Auswahl des richtigen Cloud-Anwendungsarchitekturstils für Ihre Anwendung oder Lösung;
• Auswahl geeigneter Computer- und Datenspeichertechnologien;
• Implementierung von 10 Entwicklungsprinzipien zur Erstellung einer skalierbaren, ausfallsicheren und verwaltbaren Anwendung;
• Befolgen Sie die fünf Prinzipien zur Erstellung hochwertiger Software, die den Erfolg Ihrer Cloud-Anwendung garantiert.
• Verwenden von Entwurfsmustern, die für das Problem entwickelt wurden, das Sie lösen möchten.

→ Herunterladen

Azure-Entwicklerhandbuch

In diesem Update des Azure-Entwicklerhandbuchs erfahren Sie, wie der gesamte Satz von Diensten für die Azure-Softwareplattform Ihren Anforderungen entspricht. Hier finden Sie Informationen zu Architekturansätzen und den häufigsten Situationen, die beim Erstellen von Cloud-Anwendungen auftreten.


→ Herunterladen

Microsoft Azure-Grundlagen

Dieses Buch bietet Entwicklern und IT-Fachleuten, die noch keine Erfahrung mit Cloud Computing haben, wichtige Einblicke in wichtige Azure-Dienste. Schritt-für-Schritt-Demos helfen dem Leser zu verstehen, wie er mit den einzelnen Schlüsseldiensten beginnen kann. Jedes Kapitel ist unabhängig. Es ist nicht erforderlich, praktische Demonstrationen aus früheren Kapiteln durchzuführen, um ein bestimmtes Kapitel zu verstehen.

Die folgenden Themen werden in diesem Buch behandelt:

• Erste Schritte mit Azure;
• Azure-Anwendungsdienst und Webanwendungen;
• Virtuelle Maschinen;
• Lagerservice;
• Datenbanken
• Zusätzliche Azure-Dienste.

→ Herunterladen

Nützliche Links

• ASP.NET-Dokumentation
• ASP.NET Core-Tutorials