ASP.NET Core Vor- und Nachteile

Im Anschluss an den Artikel, in dem wir diskutierten, was für Docker-Container geeigneter ist: .NET Core oder .NET Framework, werfen wir einen genaueren Blick auf die Vorteile und Nachteile von ASP.NET Core.

Als .NET-Entwicklungsunternehmen verstehen wir, dass .NET Core und ASP.NET Core zwei unabhängige Technologien sind, die sich ähneln und unterscheiden, ähnlich wie das .NET Framework und ASP.NET. In diesem Artikel werden wir die Geschichte, die Vorteile und Nachteile sowohl von ASP.NET Core als auch von .NET Core überprüfen. Darüber hinaus werden wir einige Änderungen durchgehen, die an der Architektur des ASP.NET Core-Projekts basierend auf den Bewertungen von ASP.NET-Programmierern vorgenommen wurden.

Was sind .NET Core und ASP.NET Core und warum wurden sie erstellt?

Millionen von Entwicklern haben und nutzen weiterhin ASP.NET 4.x für die Webentwicklung. Es ist eine großartige Technologie, die eine lange Entwicklungsgeschichte hat und auf ihre erste Veröffentlichung Anfang 2002 zurückgeht. Seitdem hat sich viel geändert, einschließlich des Frameworks selbst. Es gibt mindestens einige Hauptgründe, die zur Schaffung eines neuen Frameworks von Grund auf geführt haben.

Erstens, hat Microsoft viele Jahre lang Closed-Source-Software angeboten, was viele Entwickler, die Anhänger von Open Source sind, abgeschreckt hat. Einige der Microsoft-Partner hatten Zugriff auf den Quellcode, was offensichtlich nicht dasselbe ist wie Open Source. Selbst wenn man nicht zum Quellcode beiträgt, kann der Zugriff darauf helfen, genau zu verstehen, wie das Framework funktioniert und was die jeweilige Systemfunktion macht. Es ermöglicht auch der Gemeinschaft, zum Entwicklungsprozess beizutragen: einfache Verbesserungen, schnelle Diskussionen, Problemlösungen. Das alles hatten die Entwickler vorher nicht.

Zweitens, unterstützt das .NET-Framework eine bestimmte Plattform, daher ist es nicht verwunderlich, dass die Leute es nur mit Windows in Verbindung bringen. Dieser Umstand war ebenfalls ein großer Nachteil für Menschen, die das Windows-Betriebssystem nicht verwenden können oder wollen.

Drittens, hat das .NET Framework allmählich die Idee vollständig getrennt installierbarer Versionen aufgegeben, indem es keine Trennung zwischen Neben- und manchmal sogar Hauptversionen gab. Zum Beispiel koexistieren Anwendungen mit zwei verschiedenen Versionen des .NET Frameworks mit dem Risiko, Abhängigkeiten zu teilen, was Probleme verursachen kann. Was ASP.NET betrifft, das auf System.Web.dll basiert, spiegelt seine Architektur eng die Art und Weise wider, wie der IIS Anfragen verarbeitet. Aus diesem Grund ist die Trennung von ASP.NET und IIS heute nahezu unmöglich. System.Web enthält auch viele Funktionen in einem Modul, was es schwierig macht, die Funktionalität zu modularisieren und das Systemverhalten von ASP.NET zu ändern. Man kann nicht nur einen Teil der benötigten Funktionalität erhalten – man bekommt alles in einem oder gar nichts.

All diese Gründe führten dazu, den Ansatz, wie die .NET-Plattform voranschreiten sollte, neu zu überdenken und zu ändern. So wurden .NET Core und ASP.NET Core geschaffen. Beide haben das Core im Namen aus einem bestimmten Grund. Es wurde getan, um den Eindruck zu vermeiden, dass es sich nur um ein neues Update des .NET-Frameworks handelt, und um ihre Idee zu betonen, das Konzept selbst zu ändern. Trotz all dieser Fakten machen sie Ihre bestehenden Fähigkeiten nicht überflüssig. Es ist nur eine große Investition in die Zukunft der gesamten Plattform.

ASP.NET Core Vorteile

Wie oben erwähnt, ist ASP.NET Core ein neues, Open-Source, modulares, plattformübergreifendes, erweiterbares, asynchrones und viel schlankeres Framework. Es ist jetzt das einzige Framework, das entweder auf dem .NET Core 5-Laufzeit (Core-CLR) oder dem .NET Framework-Laufzeit (CLR) läuft und viele Vorteile bietet, von denen wir die meisten unten überprüfen werden.

NuGet

Im Gegensatz zum monolithischen .NET Framework besteht die .NET Core Plattform aus einer Reihe von NuGet-Paketen, die eine kleine, diskrete Funktionalität bereitstellen. Dies ermöglicht es Ihnen, Anwendungen zu optimieren, sie leichter und viel schlanker zu machen. Sie können auch eine private Version des .NET Core Frameworks für Ihre spezifische Anwendung bereitstellen, ohne dass andere Anwendungsversionen das Verhalten Ihrer Anwendung ändern können. Dies ist ein wesentlicher Vorteil von ASP.NET Core, das nicht mehr auf System.Web.dll basiert. Es kann auf mehreren Versionen von .NET Core auf derselben Maschine laufen. NuGet ermöglicht es dem ASP.NET-Team, neue Funktionen und Fehlerbehebungen viel einfacher und schneller bereitzustellen. Auf diese Weise können Sie einfach ein Upgrade durchführen, wenn Microsoft ein Upgrade für eines der Pakete bereitstellt. Mit ASP.NET Core 2.1 hat Microsoft ein Metapaket namens Microsoft.AspNetCore.App eingeführt, das alle Bibliotheken enthält, die von den .NET- und ASP.NET-Teams geliefert werden, und direkten Support bietet, ohne Sie an bestimmte Versionen von Drittanbieter-Abhängigkeiten zu binden. All dies verbessert die Leistung und Skalierbarkeit von Anwendungen.

Open Source

.NET Core und ASP.NET Core sind jetzt Open Source. Dies ist ein großer Fortschritt für die gesamte .NET-Community, da es den Entwicklungsprozess transparent und sauber macht und Entwicklern ermöglicht, sich an Code-Reviews, Fehlerbehebungen und der Bereitstellung neuer Funktionen zu beteiligen sowie die verwendeten Bibliotheken im Detail zu studieren. Eines impliziert das andere, und Open Source ermöglicht es Microsoft, die .NET-Vereinheitlichung auf plattformübergreifende Entwicklung auszudehnen, einschließlich der Entwicklung von Desktop-Apps. .NET Core hat eine einzige Codebasis, die zum Erstellen und Unterstützen aller Plattformen verwendet werden kann, einschließlich Windows, Linux und Mac OS. Offensichtlich erfordern einige einzelne Komponenten, wie das betriebssystemspezifische Dateisystem, eine separate Implementierung. Das Liefermodell über NuGet ermöglicht es, diese Unterschiede zu abstrahieren.

Single API

Ein wichtiger Aspekt für Entwickler ist, dass es sich um eine einheitliche API handelt, die auf verschiedenen Plattformen läuft. Entwickler müssen sich nicht darum kümmern, da das Paket bereits verschiedene Implementierungen für jede der Umgebungen enthält. Die Konfigurationsfunktionen wurden ebenfalls plattformübergreifend freundlicher gestaltet, indem die alten durch JSON- oder INI-Dateien und Umgebungsvariablen ersetzt wurden. Plattformübergreifend bedeutet auch, dass Sie eine größere Auswahl an Betriebssystemen für die Bereitstellung haben, da Azure ASP.NET Core sowohl in Linux- als auch in Windows-VMs unterstützt. Sie haben die Wahl.

Visual Studio Code

Ein großer Pluspunkt für diejenigen, die Visual Studio nicht installieren möchten, ist, dass Sie jetzt auch Visual Studio Code, Atom, Emacs oder sogar die Eingabeaufforderung verwenden können. Visual Studio Code beispielsweise ist der plattformübergreifende Code-Editor für Linux, MacOS und Windows. Er ermöglicht es Ihnen, ASP.NET Core-Webanwendungen, Node-Webanwendungen oder .NET Core-Konsolenanwendungen zu erstellen, zu debuggen und auszuführen, wobei IntelliSense, Codevervollständigung und Git-Integration verwendet werden können. Wenn Sie ein Anhänger von Befehlszeilen-Tools sind, werden Sie erfreut sein zu hören, dass alles, was mit dem Erstellen, Kompilieren oder Ausführen von .NET Core-Anwendungen zu tun hat, über die Befehlszeile erledigt werden kann.

Leistungsverbesserungen

Aufgrund des kleineren Fußabdrucks von ASP.NET Core gibt es auch einige leistungsbezogene Vorteile, die speziell für .NET Core gelten, aber die meisten von ihnen gelten sowohl für das .NET Framework als auch für .NET Core.

Was das Zusammenspiel von ASP.NET und IIS betrifft, so benötigt ASP.NET Core nun tatsächlich kein IIS mehr zum Ausführen. Es gibt folgende Server-Implementierungen:

• Kestrel ist der plattformübergreifende Standard-HTTP-Server für ASP.NET Core;
• IIS HTTP Server (IISHttpServer) ist eine IIS-In-Process-Server-Implementierung, die mit dem ASP.NET Core-Modul verwendet wird;
• HTTP.sys ist ein Windows-only HTTP-Server, basierend auf dem HTTP.sys-Kerneltreiber und der HTTP-Server-API.

Am beliebtesten ist Kestrel, und es ist auch der Standard in den ASP.NET Core-Vorlagen. Wenn Sie ein neues Projekt in Visual Studio erstellen, ist es automatisch so konfiguriert, dass es in Kestrel ausgeführt wird. Letzteres basiert tatsächlich auf libuv, das für I/O-Arbeiten verwendet wird und das Ausführen mehrerer Ereignisschleifen unterstützt. Obwohl Kestrel schnell, plattformübergreifend und für Durchsatzleistung optimiert ist, bietet es nicht die gesamte Funktionalität eines vollwertigen Webdienstes wie IIS, beispielsweise keine Portfreigabe, einfache SSL-Konfiguration und URL-Umschreibungen. Einige dieser Funktionen könnten in Zukunft erscheinen, aber heute wird Kestrel normalerweise mit einem Reverse-Proxy-Server wie IIS, Nginx oder Apache verwendet. Dies ist sowohl ein Vorteil als auch ein Nachteil. Kestrel ist wirklich schnell, tatsächlich sechsmal schneller als Node.js für statische und Klartext-Operationen, und bietet eine bessere Anfragenverarbeitungsleistung, aber all dies wird erreicht, weil es kein funktionsreicher Webserver ist. Warum also einen solchen Webserver erstellen, wenn man dennoch einen Proxy-Server verwenden muss? Weil man ohne ihn die Anwendung nicht ohne Änderungen auf verschiedenen Plattformen starten kann. Ohne Kestrel auf anderen plattformübergreifenden Webservern müsste der ASP.NET Core-Anwendungscode für jeden dieser Webserver geändert werden, um deren Startkriterien zu erfüllen.

Wie Sie sehen, ist ASP.NET Core eine bedeutende Veränderung. Sie können weiterhin Frameworks wie MVC, Web API, SignalR verwenden, und ihre Syntax wird sich nicht wesentlich ändern, ebenso wenig wie die Geschäftslogik, die mit Entity Framework geschrieben wurde. Es ist auch immer noch derselbe C#, F# usw. Code, und das .NET Framework steht hinter all dem. Letztendlich war das Hauptziel nicht, das .NET Framework durch .NET Core zu ersetzen, sondern eine Alternative für Entwickler zu bieten, die neue Community einzubinden, einen brandneuen Stack bereitzustellen, der den neuen Entwicklungen in der Entwicklung entspricht, und die Plattform in Zukunft zu erweitern.

ASP.NET Core Nachteile

Einige der .NET Framework-Technologien sind in der aktuellen Version von .NET Core nicht verfügbar. Tatsächlich sind einige davon für spätere Versionen geplant, aber andere werden möglicherweise nie erscheinen. Im Folgenden ist eine kurze Liste der Szenarien, in denen Sie .NET Core nicht verwenden können:

• ASP.NET Web Forms und ASP.NET Web Pages: Sie werden nur vom vollständigen .NET Framework unterstützt und bereitgestellt. In einem GitHub-Thread finden Sie eine Antwort von einem der Microsoft-Entwickler, der erklärte, dass es nicht geplant ist, WebForms auf ASP.NET Core zu portieren.
• Implementierung von WCF-Diensten: Dieses Szenario könnte für zukünftige Versionen von .NET Core in Betracht gezogen werden, aber derzeit lautet die genaueste Antwort “Nein, derzeit nicht verfügbar für .NET Core”. Die einzige verfügbare Bibliothek ist WCF-Client, die für “mobile Geräte oder Mid-Tier-Server geeignet ist, um mit bestehenden WCF-Diensten zu kommunizieren”, wie es auf ihrer GitHub-Seite heißt.
• Workflow-bezogene Dienste: Dazu gehören Windows Workflow Foundation (WF), Workflow Services (WCF + WF in einem einzigen Dienst) und WCF Data Services (früher bekannt als ADO.NET Data Services). Derzeit gibt es keine Pläne, sie auf .NET Core zu bringen.
• Windows Forms und Windows Presentation Foundation (WPF) Anwendungen: Diese werden noch nicht unterstützt. Allerdings gibt es gute Nachrichten: Anfang dieses Jahres kündigte Microsoft an, dass sie die erste Preview-Version von .NET Core 3 gegen Ende dieses Jahres und die endgültige Version im Jahr 2019 planen. Dieses neue Release wird die Möglichkeit beinhalten, neue und bestehende Windows-Desktop-Anwendungen auf .NET Core auszuführen und alle Vorteile zu nutzen, die .NET Core bietet. Die Unterstützung für Windows-Desktops wird als eine Reihe von “Windows Desktop Packs” hinzugefügt, die nur auf Windows funktionieren.
• Fehlende Unterstützung von Drittanbieterbibliotheken: .NET Core 2.0 bietet eine Kompatibilitätsschicht zwischen dem .NET Framework und .NET Core, aber es können dennoch Kompatibilitätsprobleme auftreten, wenn die Klassenbibliothek .NET Framework-APIs verwendet, die nicht unterstützt werden.
• Windows-spezifische APIs: Sie können Windows-spezifische APIs in ASP.NET Core und .NET Core nicht verwenden, da diese Frameworks so konzipiert sind, dass sie unabhängiger vom Betriebssystem sind. Beispielsweise können Sie den System.Drawing-Namespace oder die Arbeit mit der Windows-Registrierung nicht verwenden, hierfür sollten Sie das .NET Framework verwenden.

Es gibt viele Diskussionen in GitHub-Threads zum Thema Portierung von .NET Framework-Bibliotheken auf .NET Core, und dies ist ein gutes Beispiel dafür, wie Open Source die Projektentwicklung beeinflussen kann. Wenn Sie diese Threads öffnen, sehen Sie, dass Microsoft-Mitarbeiter auf jedes Problem antworten, Pläne zur Portierung von Technologien besprechen und die Gründe erörtern, warum diese Portierung benötigt wird, um genau zu wissen, was für Entwickler notwendig ist. Offensichtlich wird es Technologien geben, die überhaupt nicht portiert werden, da sie mit dem Windows-Betriebssystem verbunden sind, während .NET Core entwickelt wurde, um plattformübergreifende Unterstützung zu bieten.

Nun, da wir alle wichtigen Änderungen in .NET Core und ASP.NET Core überprüft haben, lassen Sie uns zu einer neuen Anwendungsstruktur und den Änderungen übergehen, die in einem neuen Projekttyp bestehen.

Grundlagen von ASP.NET Core

In diesem Abschnitt erstellen wir ein Testprojekt, um Änderungen in der Struktur anhand eines realen Beispiels zu überprüfen. Nehmen wir an, dass Sie mindestens einmal ein neues Projekt mit Visual Studio erstellt haben. Wir werden die Option überprüfen, eine neue Lösung zusammen mit dem Projekt mithilfe einer Konsole zu erstellen.

Um eine Lösung zu erstellen, öffnen Sie die Konsole (wir verwenden Windows PowerShell, aber Sie können auch die Eingabeaufforderung verwenden) und führen Sie den folgenden Befehl aus:

Hierbei ist dotnet new ein Befehl, mit dem Sie ein neues Projekt, eine Konfigurationsdatei oder eine Lösung basierend auf der angegebenen Vorlage mit allen erforderlichen Abhängigkeiten erstellen können. In diesem Fall haben wir angegeben, dass wir eine Lösung mit der Option sln erstellen möchten und haben die Option -n hinzugefügt, um den Namen des Projekts festzulegen. Wenn Sie den Namen nicht angeben, wird er automatisch auf den gleichwertigen Namen des Ordners gesetzt. Sie können auch den Befehl dotnet new -l verwenden, um eine Liste aller verfügbaren Vorlagen zu erhalten. Nachdem Sie diesen Befehl ausgeführt haben, sehen Sie, wenn Sie den Ordner öffnen, eine neu erstellte Lösung.

Bezogen auf die Standardstruktur des Projekts, erstellen Sie einen neuen Ordner neben der Lösung auf eine der folgenden Arten:

• Manuell im Dateiexplorer;
• In PowerShell mit dem Befehl md CoreAppProj;
• In der Linux-Konsole mit dem Befehl mkdir CoreAppProj.

Wechseln Sie in dieses neue Verzeichnis und erstellen Sie das Projekt mit dem Befehl:

Die Option mvc bedeutet, dass der Projekttyp ASP.NET Core Web App (Model-View-Controller) sein wird und der Name auf den Ordnernamen gesetzt wird. Um die Lösung und das Projekt zu verknüpfen, kehren Sie zum Lösungsordner zurück und führen Sie den folgenden Befehl aus:

Wenn Sie das Projekt jetzt in Visual Studio öffnen, sehen Sie ein standardmäßig erstelltes Projekt:

Wenn Sie die Projektdateien sorgfältig überprüfen, werden Sie feststellen, dass das .csproj-Dateiformat in ASP.NET Core vereinfacht wurde. Lassen Sie uns die wichtigsten Änderungen Schritt für Schritt überprüfen.

Program.cs

In ASP.NET Core ist der Einstiegspunkt einer Anwendung Startup.cs, und Sie haben keine Abhängigkeit mehr von Global.asax. ASP.NET Core behandelt den Einstieg über die Main-Methode von Program.cs (ähnlich wie Konsolenanwendungen, und eine ASP.NET Core-Anwendung ist tatsächlich eine Konsolenanwendung) und Startup wird dort geladen:

Die „Main“-Methode verwendet den WebHostBuilder, der das Builder-Muster folgt, um einen Webanwendungshost zu erstellen. Der Builder umfasst:

• CreateDefaultBuilder(args): Die Methode, die eine neue Instanz der WebHostBuilder-Klasse mit vorkonfigurierten Standardeinstellungen initialisiert;
• UseStartup(): Die Methode, die die Startup-Klasse definiert. Wenn Sie die Anwendung starten, sucht die ASP.NET-Umgebung nach einer Klasse im Anwendungsassembly namens Startup und lädt sie. Der Name „Startup“ ist der Standardname, aber Sie können ihn nach Belieben umbenennen. Nur die standardmäßige Konstruktion dieser Klasse ist erforderlich.

Wie oben erwähnt, sollte der Standardserver Kestrel sein, und oft treffen Sie auf die folgende Realisierung:

Beide Realisierungen (oben und in unserem Beispiel) sind gut. Sie müssen nur wissen, dass die Verwendung der Methode „CreateDefaultBuilder“ bedeutet, dass die folgenden Standardeinstellungen angewendet werden (bereitgestellt von der offiziellen Microsoft-Dokumentation):

• Verwendung von Kestrel als Webserver und Konfiguration über die Konfigurationsanbieter der Anwendung;
• Setzen des ContentRootPath auf das Ergebnis von GetCurrentDirectory();
• Laden von IConfiguration aus appsettings.json und appsettings.[EnvironmentName].json;
• Laden von IConfiguration aus User Secrets, wenn EnvironmentName ‘Development’ ist, unter Verwendung des Entry-Assemblies;
• Laden von IConfiguration aus Umgebungsvariablen;
• Konfigurieren der ILoggerFactory, um in die Konsole und die Debug-Ausgabe zu protokollieren;
• Aktivieren der IIS-Integration;
• Ermöglichen von Frameworks, ihre Optionen an ihre Standardkonfigurationsabschnitte zu binden.

Sie können die Parameter manuell ändern und einen anderen Webserver festlegen. Die Methoden Build und Run erstellen das IWebHost, das die App hostet und so konfiguriert, dass es eingehende HTTP-Anfragen akzeptiert.

Startup.cs

Die Methode UseStartup auf WebHostBuilder definiert die Startup-Klasse der Anwendung, in der die Anforderungspipeline der Anwendung definiert wird und alle Dienste konfiguriert werden. Ein Startup muss eine Configure-Methode enthalten, in der das notwendige Middleware zur Pipeline hinzugefügt wird. Unten ist ein generiertes Codebeispiel, das Sie nach dem Erstellen eines Projekts sehen sollten:

ConfigureServices definiert die Dienste, die von der Anwendung verwendet werden, und Configure definiert die Middleware in der Anforderungspipeline. Im obigen Beispiel konfiguriert die Configure-Methode die Pipeline mit Unterstützung für:

• Fehlerseiten
• HTTP Strict Transport Security
• HTTP-Umleitung zu HTTPS
• ASP.NET Core MVC

Middleware

ASP.NET Core-Middleware sind Codeabschnitte, die asynchrone Logik auf einem HttpContext ausführen. Eingehende Anfragen werden durch die Pipeline geleitet, wobei jede Middleware die nächste Middleware in der Pipeline aufruft oder die Anforderung beendet. Middleware kann jede Art von Operationen ausführen, wie z.B. Authentifizierung, Fehlerbehandlung, statische Dateien usw. Zum Beispiel ist MVC in ASP.NET Core auch als Middleware implementiert. Tatsächlich können Sie entweder benutzerdefinierte Middleware erstellen oder die benötigte aus einer großen Menge integrierter Middleware verwenden, und Sie können Ihre eigene benutzerdefinierte Middleware schreiben. Im obigen Beispiel sind die Middlewares:

• UseDeveloperExceptionPage: Ermöglicht das Anzeigen detaillierter Ausnahmeinformationen. Es wird dringend empfohlen, dies nur auf Staging zu verwenden. Der Aufruf dieser Middleware sollte vor der Middleware erfolgen, bei der Sie Ausnahmen abfangen möchten, z.B. vor app.UseMvc().
• UseExceptionHandler: Konfiguriert eine Fehlerhandler-Seite. Wird normalerweise in der Produktion anstelle von UseDeveloperExceptionPage verwendet, sodass dem Benutzer die von Ihnen angegebene Seite angezeigt wird, wenn ein Fehler auftritt.
• UseHsts: Wird verwendet, um HTTP Strict Transport Security Protocol (HSTS)-Header an Clients zu senden.
• UseHttpsRedirection: Wird verwendet, um HTTP-Anfragen auf HTTPS umzuleiten.
• UseStaticFiles: Die parameterlose UseStaticFiles-Methode ermöglicht den Zugriff auf Dateien im Ordner über den Webbrowser. Beispielsweise können Sie den Pfad zu einer beliebigen Datei aus dem wwwroot-Ordner in das Markup einfügen und sie wird für Benutzer sichtbar sein. Der Ordner wwwroot (/wwwroot) ist das Standardverzeichnis, kann aber manuell geändert werden.
• UseCookiePolicy: Aktiviert die Cookie-Richtlinienfunktionen in einer App. Beeinflusst auch nur die Komponenten, die danach in der Pipeline registriert sind.

Konfiguration

ASP.NET Core hat auch sein Konfigurationsmodell für die Handhabung einfacher Name-Wert-Paare geändert. Das neue Konfigurationsmodell basiert auf Schlüssel-Wert-Paaren, die von Konfigurationsanbietern erstellt wurden, anstatt sich auf System.Configuration oder web.config zu verlassen. Konfigurationsanbieter können Konfigurationsdaten aus verschiedenen Dateiformaten lesen: XML, JSON, INI sowie aus Umgebungsvariablen, Befehlszeilenargumenten oder einer In-Memory-Sammlung. Sie können auch Ihren eigenen benutzerdefinierten Konfigurationsanbieter schreiben. Standardmäßig sollten Sie in Ihrem Testprojekt, das wir oben erstellt haben, eine automatisch erstellte JSON-Datei mit dem Namen appsettings.json sehen. Sie können Verbindungszeichenfolgen hinzufügen, zulässige Hosts festlegen und fortfahren.

Environment Variables Configuration Provider

Das neue Konfigurationsmodell ermöglicht auch die Verwendung von Umgebungsvariablen über den EnvironmentVariablesConfigurationProvider, der Konfigurationen aus Schlüssel-Wert-Paaren von Umgebungsvariablen zur Laufzeit lädt. Um die Konfiguration von Umgebungsvariablen zu aktivieren, sollten Sie die Erweiterungsmethode AddEnvironmentVariables auf einer Instanz von ConfigurationBuilder aufrufen. Wenn die Anwendung läuft, wird der Environment Variables Configuration Provider direkt nach der Konfiguration durch User Secrets und Appsettings-Dateien aufgerufen. Der Aufruf des Providers in dieser Position ermöglicht es, dass die Umgebungsvariablen zur Laufzeit gelesen werden und die Konfiguration, die durch User Secrets und Appsettings-Dateien festgelegt wurde, überschreiben.

Ausführen der Anwendung

Am Anfang des Abschnitts haben wir bereits kurz die Möglichkeiten zur Entwicklung von Anwendungen mit den .NET Core CLI-Tools besprochen, sodass Sie nun ein Projekt haben müssen, für das wir noch einige weitere Befehle überprüfen, um dieses grobe Überblickstutorial abzuschließen.
Wenn Sie nach Informationen zum Ausführen einer Anwendung über die CLI suchen, finden Sie mindestens 3 Befehle:

• dotnet restore: Ruft NuGet auf, das die Datei CoreAppProj.csproj analysiert, die in der Datei definierten Abhängigkeiten herunterlädt (oder sie aus einem Cache auf Ihrem Computer bezieht) und die Datei obj/project.assets.json schreibt, die zum Kompilieren und Ausführen des Codes erforderlich ist.
• dotnet build: Baut ein Projekt und alle seine Abhängigkeiten.
• dotnet run: Führt den Quellcode aus.

Tatsächlich müssen Sie, wenn Sie das .NET Core 2.0 SDK verwenden, nur den letzten Befehl aus dieser Liste verwenden. Der Befehl dotnet restore wird implizit von allen Befehlen ausgeführt, die einen Neustart erfordern: dotnet new, dotnet build und dotnet run. Dieser Befehl wird in bestimmten Fällen noch verwendet, ist aber in diesem speziellen Fall nicht erforderlich. Was den Befehl dotnet build betrifft, so wird er auch vom Befehl dotnet restore aufgerufen, um sicherzustellen, dass die Build-Ziele erstellt wurden. Daher werden bei Ausführung des Befehls dotnet run die Projektabhängigkeiten heruntergeladen, das Projekt gebaut und die Anwendung ausgeführt. Das ist alles! Jetzt können Sie diese grundlegenden Konzepte verwenden, um eine Anwendung zu erstellen und Ihre Fähigkeiten zu verbessern.

Fazit

.NET Core und ASP.NET Core beinhalten viele neue Verbesserungen und grundlegende Änderungen, die Ihnen bei der täglichen Entwicklung helfen sollten. Würden Sie glauben, wenn jemand in der Vergangenheit gesagt hätte, dass Microsoft Open-Source- und plattformübergreifende Lösungen anbieten würde? Wahrscheinlich nicht. Aber die Zeiten ändern sich, und heute bietet Microsoft großartige Lösungen an, die immer mehr Entwickler anziehen. Deshalb glauben wir, dass die Zukunft noch größere Veränderungen bereithält, die wir in anderen Artikeln behandeln werden.