Neues in ASP.NET 5, Teil 3: Änderungen in Visual Studio 2015

Seite 3: Und was noch, oder was nicht?

Inhaltsverzeichnis

Vergeblich wird der ASP.NET-Entwickler eine web.config-Datei suchen. Anstelle des in .NET etablierten XML-Formats verwendet Microsoft nun auch hier JSON-Dateien. Die project.json-Datei konfiguriert die Abhängigkeiten zu NuGet-Paketen, die DNX-Varianten, für die zu kompilieren ist, welche Dateien nicht zu übersetzen und nicht zu verbreiten sind, und schließlich auch die Versionsnummer für die Anwendung (eine AssemblyInfo.cs-Datei gibt es also nicht mehr). Anwendungseinstellungen wie Verbindungszeichenfolgen speichert Microsoft in der config.json. Selbst beliebige andere Anwendungseinstellungen kann man hier ablegen. Microsoft zeigt das in der ASP.NET-5-Website-Projektvorlage in den Klassen Properties/AppSettings.cs und Startup.cs. Im Programmcode kann man die Einstellungen dann über die Klasse AppSettings abrufen.

Wie bisher liefert Microsoft in der Projektvorlage eine komplette Benutzerkontenverwaltung mit (siehe /Controller/AccountController.cs, /Controller/ManageController.cs sowie /Views/Account und /View/Manage). Dazu gehört die Programmcodedatei MessageService.cs, die noch von Entwicklern auszufüllende Methoden für E-Mail- oder SMS-Versand enthält.

Neu ist auch die Datei /Views/_GlobalImport.cshtml, die Tag Helper global für alle Views registriert. Im ersten Teil der Artikelstrecke wurde diese Datei noch mit _ViewStart.cshtml benannt. Microsoft hat hier mittlerweile eine Namensänderung vollzogen.

Für den beliebten Codegenerator Yeoman gibt es zahlreiche Projekt- und Projektelementvorlagen für ASP.NET 5.0 (z. B. für ASP.NET MVC Views und Controller sowie diverse andere in ASP.NET-Projekten einsetzbare Dateiarten wie SCSS, LESS und JSX). Laut dem Stand-up-Treffen der ASP.NET-Community vom 7. Juli 2015 ist aber nicht geplant, Yeoman direkt in Visual Studio zu integrieren und anstelle des Projektvorlagensystems von Visual Studio (s. Abb. 1 und 3) zu nutzen. Das wird mit folgender Stellungnahme begründet: "Microsoft wants to deliver curated content as the starter experience". Yeoman lässt sich aber über die Kommandozeile nutzen, um ASP.NET-Projekte zu erzeugen oder zu erweitern.

Wer auf diese Weise ein Webprojekt in Visual Studio mit dem Debugger startet, wird zwar eine Webseite im Browser sehen (s. Abb. 5), aber vergeblich auf der Festplatte nach einem Kompilat suchen. Standardmäßig kompiliert Visual Studio 2015 die neuen ASP.NET-5-Webprojekte nur noch im RAM. Wer DLLs auf der Festplatte sehen will, muss in den Projekteigenschaften unter "Build" ein Häkchen bei "Produce outputs on build" setzen. Alternativ kann man das Kommandozeilenwerkzeug ".NET Utility" (dnu.cmd) mit dem Parameter "build" nutzen. Durch die Übersetzung entsteht unterhalb von /src/HeiseWeb/bin/Debug für jede DNX-Version ein Unterverzeichnis mit einer DLL-Assembly. Dass der /bin-Ordner ein Unterordner des Quellcodeordners (/src) ist, ist unlogisch. Ihn hätte Microsoft besser auf gleicher Ebene wie /src angesiedelt. Auch die Namenstrennung zwischen /artifacts (für Übersetzungszwischenprodukte) und /bin (für endgültige Übersetzungsprodukte) ist nicht intuitiv zu verstehen.

Die Publish-Funktion in Visual Studio oder die Anweisung dnu publish an der Kommandozeile bewirkt, dass die komplette Zielstruktur der Webanwendung im Ordner /src/HeiseWeb/bin/output entsteht (s. Abb. 8).

Ausgabestruktur einer ASP.NET-5-Webanwendung (Abb. 8)

Hier findet man nicht nur den Ordner /wwwroot wieder, sondern auch einen Ordner /approot, der den kompletten Quellcode enthält. Den Quellcode auf das Zielsystem zu verbreiten, ist der von Microsoft favorisierte Weg. Es gibt aber auch eine Option, den Quellcode in kompilierter Form (als NuGet-Paket) zu verbreiten. In jedem Fall bleibt jedoch der Programmcode getrennt vom /wwwroot-Ordner, um zu verhindern, dass jemand den Programmcode perHTTP-Anfrage herunterladen kann (in früheren ASP.NET-Versionen gab es dafür spezielle Filter, die den Zugriff auf den /bin-Ordner geblockt haben).

Der Veröffentlichungsassistent für Webprojekte in Visual Studio 2015 erzeugt ein anpassbares PowerShell-Skript. Microsoft legt viel Wert darauf, dass sich ASP.NET-5-Anwendungen auch ohne Visual Studio entwickeln lassen, und liefert daher für alle zentralen Aufgaben Kommandozeilenwerkzeuge. Da es die PowerShell jedoch nur unter Windows gibt, nutzt der Softwarekonzern auf Linux- und OS-X-Systemen die Bash Shell.