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

21.07.2015 10:38 Uhr Dr. Holger Schwichtenberg

Auch in seiner Entwicklungsumgebung öffnet sich Microsoft. In Visual Studio 2015 findet man in ASP.NET-5-Webprojekten eine Menge Open-Source-Werkzeuge.

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

Auch in seiner Entwicklungsumgebung öffnet sich Microsoft. In Visual Studio 2015 findet man in ASP.NET-5-Webprojekten eine Menge Open-Source-Werkzeuge. Selbst bei der Projektstruktur verabschieden sich die Redmonder von Traditionen.

Bereits beim Anlegen eines Webprojekts in Visual Studio 2015 fallen einige Merkwürdigkeiten auf. Als Erstes ist kurios, dass es im Dialog "New Project" unter Visual C# | Web beziehungsweise Visual Basic | Web (s. Abb. 1) nicht nur einen Eintrag "Web Application" gibt, hinter dem sich dann aber ein weiterer Dialog mit mehreren Projektvorlagen verbirgt, sondern darüber hinaus auch zwei neue Einträge "Class Library" und "Console Application".

Erster Schritt beim Anlegen eines neuen Webprojekts (Abb. 1)

Verwirrung um die Projektvorlagen

Dass im Dialog aus Abbildung 1 Klassenbibliotheken und Konsolenanwendungen erscheinen, liegt daran, dass Microsoft im Zuge der Generalüberholung von ASP.NET eine neue Form plattformneutraler Klassenbibliotheken und Konsolenanwendungen geschaffen hat. Sie laufen – genauso wie ASP.NET-5-Webanwendungen – nicht direkt auf einer bestimmten .NET-Framework-Version, sondern auf einer Zwischenschicht, die Microsoft .NET Execution Environment (DNX) nennt (s. Abb. 2).

ASP.NET 5.0 läuft auf .NET 4.6, Mono (ab Version 3.4.1) und .NET Core 5.0 (Abb. 2).

DNX abstrahiert von den Unterschieden verschiedener .NET-Varianten auf diversen Plattformen. Dafür stellt DNX Entwicklerwerkzeuge und eine Ausführungsumgebung zur Laufzeit bereit.

Konsolenanwendungen in ASP.NET 5 erzeugen keine direkt ausführbaren Dateien ([.exe), sondern DLLs, die mit dem Werkzeug DNX(.exe) zu starten sind. Gedacht sind diese Konsolenanwendung primär für Web-Worker-Prozesse in Microsofts Cloud-Umgebung Azure. Klassenbibliotheken in ASP.NET 5 lassen sich von Konsolen- und Webanwendungen referenzieren. Sie erfüllen die gleiche Wiederverwendungsfunktion wie klassische .NET-Klassenbibliotheken.

Neues in ASP.NET 5

Tag Helper [1]
View Components [2]
Änderungen in Visual Studio 2015

Ob beziehungsweise wann DNX und seine speziellen Projekte für andere Anwendungsarten allein als Webprojekte verfügbar sein wird, ist noch unklar. Vorerst sind die beiden Projektvorlagen unter "Web" richtig aufgehoben. Die Symbole dieser Projektvorlagen zeigen allerdings in Visual Studio 2015 noch "vNext". Das bis zum Erscheinen von Visual Studio 2015 noch zu ändern, hat Microsoft jedoch angekündigt.

Im Dialog zum Anlegen von Webprojekten in Abbildung 1 fällt auch auf, dass man nur zwischen .NET Framework 2.0 bis .NET Framework 4.6 wählen kann. In dem dafür angelegten Auswahlfeld gibt es verwirrenderweise kein .NET Core 5.0. An dieser Stelle muss man wissen, dass alle ASP.NET-5-Projekte standardmäßig so eingestellt sind, dass sie sowohl auf .NET Framework 4.6 als auch auf .NET Core 5.0 kompilieren. Hier ist also die Version 4.6 erst mal die richtige Wahl.

Wenn man nun im ersten Dialog ASP.NET Web Application wählt, folgt ein zweiter Auswahldialog (s. Abb. 3). Hier hat man nun die Wahl zwischen ASP.NET 4.6 Templates und ASP.NET 5 Preview Templates. Unter Ersteren findet man die Projektvorlagen, die es schon in Visual Studio 2013 gab, also für ASP.NET Web Forms 4.x, ASP.NET MVC 5.x und ASP.NET Web API 2.x – mit der Option, diese drei namensähnlichen, aber doch verschiedenen Techniken in einem einzigen Projekt mischen zu können. Diesen Mix ermöglicht Microsoft seit Visual Studio 2013 unter dem Marketingbegriff "One ASP.NET".

Ein tatsächliches "One ASP.NET" gibt es aber erst in ASP.NET 5.0, denn hier sind ASP.NET MVC und ASP.NET Web API wirklich ein Framework. Der neue Oberbegriff ist "ASP.NET MVC 6". Ein Controller in diesem liefert entweder eine View (also eine HTML-Seite) oder JSON-Daten für eine Web API. In beiden Fällen ist die Basisklasse Microsoft.AspNet.Mvc.Controller. Die Auswahl zwischen Web API und Web Site im zweiten Dialog aus Abbildung 3 entscheidet nur, ob man ein Muster für einen Controller bekommt, der eine View liefert, oder Daten. Wünschenswert wäre eine Projektvorlage, die beides demonstriert; aber diese gibt es bedauerlicherweise noch nicht.

Zweiter Schritt beim Anlegen eines neuen Webprojekts (Abb. 3)

Open Source inside

Ein Gewimmel von Open-Source-Tools

Eine mit den ASP.NET-5-Vorlagen angelegte Website und ein Web-API-Dienst im Projektmappen-Explorer von Visual Studio 2015 (Abb. 4)

Die nächste Verwunderung gibt es für altgediente ASP.NET-Entwickler nach dem Anlegen eines Projekts mit den ASP.NET-5-Vorlagen "Web API" und "Web Site". Im Projektmappen-Explorer sieht man jetzt einige ganz neue Einträge (s. Abb. 4).

Unter "Solution" gibt es nun einen neuen Ordner /src (für Source) und erst darunter die Projekte. Auf der Festplatte gibt es zusätzlich den im Projektmappen-Explorer nicht sichtbaren weiteren Ordner /artifacts für temporäre Produkte während des Übersetzungsvorgangs. Endprodukte dürfen hier jedoch nicht liegen. Über diese Verzeichnisstruktur gab es in den letzten Monaten umfangreiche Diskussionen auf GitHub [3].

Der Ast "Referenzen" teilt sich in die beiden angesprochenen DNX-Varianten (wobei im Visual Studio 2015 Release Candidate die Bezeichnung DNX 4.5.1 falsch ist. Dort müsste DNX 4.6 stehen).

Der neue Projektmappenordner wwwroot, den es unter /src/wwwroot auch auf der Festplatte gibt, enthält alle statischen Dateien des Projekts (HTML, CSS, JavaScript, Grafiken, favicon.ico usw.). Er repräsentiert später die Zielstruktur.

Ebenfalls neu ist der Ast "Dependencies", den es so im Dateisystem allerdings gar nicht gibt. Die beiden Zweige "Dependencies/Bower" und "Dependencies/NPM" listen die verwendeten Pakete von Twitter Bower [4] und Node Package Manager [5]. Die Paketlisten ergeben sich aus den Dateien bower.json (für Bower) und package.json (für NPM) beziehungsweise dem Inhalt der Dateisystemordner bower_components und node_modules. Für die Verwaltung der Abhängigkeiten zu Bower und NPM gibt es in Visual Studio noch keine grafische Benutzeroberfläche wie bei Microsofts eigenem Paketmanager NuGet [6]; die JSON-Dateien bieten eine hilfreiche Eingabeunterstützung für die Paketnamen und Versionsnummern (s. Abb. 5).

Visual Studio 2015 bietet Eingabeunterstützung für sowohl Paketnamen als auch Versionsnummern, und zwar für alle drei Paketmanager NuGet, Bower und NPM (Abb. 5)

Zu den im Standard geladenen Bower-Paketen gehören jQuery, jQuery Validation, hammer.js für Touch-Gesten [7], Twitter Bootstrap und Twitter Touch Carousel [8]. Letzteres ist allerdings ein Paket, das seit über einem Jahr auf Version 0.8 steht und das auf der GitHub-Seite informiert: "This package is no longer maintained! We're searching for contributors". Es ist kurios, dass Microsoft in seinen Webprojektvorlagen auf so ein verwaistes Paket setzt. Die Beispiel-Webanwendung im Responsive Web Design, die die Projektvorlage aus diesen Bausteinen zusammensetzt, sieht man in Abbildung 6.

Die Projektvorlage für ASP.NET-5-Websites in Aktion (Abb. 6)

Gulp oder Grunt?

Bei den NPM-Paketen findet man den Node.js-basierten Task Runner Gulp [9] und das von Gulp verwendete Paket rimraf [10], das Verzeichnisse rekursiv löschen kann. Dazu passend enthält die Datei gulpfile.js die Aufgabendefinitionen für Gulp. Im Standard findet man in der Datei die Aufgabe "copy", die Dateien aus dem Verzeichnis bower_components nach wwwroot/lib kopiert, sowie die Aufgabe "clean", die den kompletten Inhalt des Ordners wwwroot/lib löscht. Über das neue Visual-Studio-Fenster "Task Runner Exlorer" (s. Abb. 7) können Entwickler die Aufgaben zu den vier Ereignissen "Before Build", "After Build", "Clean" und "Solution Open" zuweisen. Die Zuweisung speichert Visual Studio in einem Kommentar zu Beginn der Datei gulpfile.js.

In Gulp und Grunt definierte Aufgaben kann man im Task Runner Explorer vier Ereignissen in Visual Studio per "Binding" zuweisen (Abb. 7).

Neben Gulp unterstützt der Task Runner Exlorer den Gulp-Konkurrenten Grunt [11]. Ihn muss man als NPM-Paket nachinstallieren (s. Abb. 6) und dann dem Projekt eine Datei gruntfile.js hinzufügen. Sodann erscheinen die dort definierten Aufgaben auch im Task Runner Explorer (s. Abb. 7). Ein grundsätzlicher Unterschied zwischen Gulp und Grunt ist, dass die Konfiguration bei Gulp in JavaScript-Syntax erfolgt:

/// <binding AfterBuild='copy' Clean='clean' />
var gulp = require("gulp"),
  rimraf = require("rimraf"),
  fs = require("fs");

eval("var project = " + fs.readFileSync("./project.json"));

var paths = {
  bower: "./bower_components/",
  lib: "./" + project.webroot + "/lib/"
};

gulp.task("clean", function (cb) {
  rimraf(paths.lib, cb);
});

gulp.task("copy", ["clean"], function () {
  var bower = {
    "bootstrap": "bootstrap/dist/**/*.{js,map,css,ttf,svg,woff,eot}",
    "bootstrap-touch-carousel": 
            "bootstrap-touch-carousel/dist/**/*.{js,css}",
    "hammer.js": "hammer.js/hammer*.{js,map}",
    "jquery": "jquery/jquery*.{js,map}",
    "jquery-validation": "jquery-validation/jquery.validate.js",
    "jquery-validation-unobtrusive": 
          "jquery-validation-unobtrusive/jquery.validate.unobtrusive.js"
  }

  for (var destinationDir in bower) {
    gulp.src(paths.bower + bower[destinationDir])
      .pipe(gulp.dest(paths.lib + destinationDir));
  }
});

Grunt verwendet hier hingegen im Wesentlichen JSON verwendet.

/// <binding AfterBuild='less' />
// This file in the main entry point for defining grunt tasks and 
// using grunt plugins. Click here to learn more. 
// http://go.microsoft.com/fwlink/?LinkID=513275&clcid=0x409

module.exports = function (grunt) {
 grunt.initConfig({

  // fuer LESS:
  less: {
   development: {
    options: {
     paths: ["Assets"],
    },
    files: { "wwwroot/css/site2.css": "assets/site2.less" }
   },
  },
  bower: {
   install: {
    options: {
     targetDir: "wwwroot/lib",
     layout: "byComponent",
     cleanTargetDir: false
    }
   }
  }
 });

 // This command registers the default task which will 
 // install bower packages into wwwroot/lib
 grunt.registerTask("default", ["bower:install"]);
 grunt.registerTask("default", ["less:development"]);
 // The following line loads the grunt plugins.
 // This line needs to be at the end of this this file.
 grunt.loadNpmTasks("grunt-bower-task");

 // Zusatz fuer LESS-Task:
 grunt.loadNpmTasks("grunt-contrib-less");
};

Gulp ist damit oft flexibler.

Und was noch, oder was nicht?

Was man vermissen könnte

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 [12] wurde diese Datei noch mit _ViewStart.cshtml benannt. Microsoft hat hier mittlerweile eine Namensänderung vollzogen.

Für den beliebten Codegenerator Yeoman [13] 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 [14] 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.

Debugging und Deployment

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 [15]. 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.

Fazit

Für Entwickler, die mit bisherigen Versionen von ASP.NET gearbeitet haben, ist der Aufbau von ASP.NET-5-Projekten ein Kulturschock. Es gibt zwei wesentliche Änderungen: die neue Projektstruktur und die Integration der Open-Source-Werkzeuge.

Bei der neuen Webprojektstruktur ist leider festzuhalten, dass diese nicht intuitiv zu verstehen ist, was auch an den Diskussionen auf GitHub zu sehen ist. Insbesondere erschließt sich nicht, warum ein dezidierter Ordner für Quellcode (/src) eingeführt wurde, unter dem dann aber in /bin auch Kompilate zu finden sind. Ebenso ist die Namensgebung des /artifacts-Ordners unglücklich.

Hingegen ist die Öffnung von Visual Studio für etablierte Open-Source-Werkzeuge der Webwelt zu begrüßen. Bisher hat Microsoft viele notwendige Tools im Rahmen der Webentwicklung (z. B. Kopiervorgänge, Transkompilierung, Minifizierung) entweder in Visual Studio eingebaut oder als Add-in geliefert (siehe Web Essentials for Visual Studio [16]). Nun erlaubt Microsoft seinen Kunden, auf einfache Weise auf die vielen tausend Automatisierungslösungen zuzugreifen, die die Node.js-Welt bereits geschaffen hat. Zudem gibt es bei Bower mehr Pakete für Webanwendungen als bei Microsofts eigenem Paketportal NuGet.org.

Das war also ein guter Schritt. Dennoch ist es auch möglich, hier aus einem anderen Blickwinkel auf die Sache zu schauen: Bisher bekamen die ASP.NET-Entwickler ein Gesamtpaket von Microsoft geliefert. Nun haben Sie die Qual der Wahl aus vielen tausend Paketen, deren Urheber man oft nicht genau kennt. Dass man dabei leicht daneben greifen kann, hat der Softwarekonzern mit der Aufnahme des verwaisten Projekts bootstrap-touch-carousel in die Projektvorlage eindrucksvoll bewiesen.

Dr. Holger Schwichtenberg
leitet das Expertennetzwerk www.IT-Visions.de [17], das Beratung, Schulungen und Softwareentwicklung im Umfeld von .NET und Web-Techniken anbietet. Er hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher. (ane [18])

URL dieses Artikels:
https://www.heise.de/-2751695

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Neues-in-ASP-NET-5-Teil-1-Tag-Helper-2573410.html
[2] https://www.heise.de/hintergrund/Neues-in-ASP-NET-5-Teil-2-View-Components-2639138.html
[3] https://gist.github.com/davidfowl/ed7564297c61fe9ab814
[4] http://bower.io/
[5] https://www.npmjs.com/
[6] http://www.nuget.org/
[7] http://hammerjs.github.io/
[8] https://github.com/ixisio/bootstrap-touch-carousel
[9] http://gulpjs.com/
[10] https://www.npmjs.com/package/rimraf
[11] http://gruntjs.com/
[12] https://www.heise.de/hintergrund/Neues-in-ASP-NET-5-Teil-1-Tag-Helper-2573410.html
[13] http://yeoman.io/
[14] http://blogs.msdn.com/b/webdev/archive/2015/07/07/asp-net-community-standup-july-7-2015.aspx
[15] https://github.com/aspnet/vsweb-publish
[16] http://vswebessentials.com/
[17] http://www.it-visions.de/start.aspx
[18] mailto:ane@heise.de