Visual Studio 2012 RC – Web-Tools

Gestern habe ich einen ersten groben Überblick über den RC des neuen VS gegeben. Wie ich bereits angerissen hatte, ist vor allem – und nicht überraschend – im Bereich Web-Entwicklung einiges an Neuem zu erwarten. Dieser Artikel wagt einen tieferen Blick.

Webcast

Vorbemerkungen

Das neue Visual Studio bringt natürlich auch Nicht-Web-Entwicklern einige wichtige Neuerungen und Verbesserungen. Angesichts der aktuellen Strategie nicht nur von Microsoft, so gut wie alles im Web zu entwickeln und mit Clouds zu verbinden kann allerdings nicht weiter überraschen, das Visual Studio als DAS zentrale Tool dafür sehr web- und Azure-lastig daherkommt. Azure will ich hier in meiner Eigenschaft als deutscher Blogger nicht zu sehr in den Vordergrund bringen, weil es einfach in unseren Breitengraden zu vage Rahmenbedingungen im professionellen Bereich gibt. Bleibt also zunächst einmal der Web-Bereich, den ich hier aus meiner persönlichen Brille betrachten möchte.

Web-Tools – was heißt das?

Zugegeben, Web-Tools ist ein sehr weit gefasster Begriff. Zum einen möchte ich die mir bereits bekannten Neuerungen bei der Unterstützung im ganz normalen Web-Development-Bereich darstellen. Das hat also noch nichts mit MVC oder ähnlichen Aufsätzen zu tun. Genau diese werde ich dann in einem eigenen Artikel, soweit es mir, wie gesagt, bereits möglich ist behandeln. Die tieferen Erkenntnisse stellen sich ja gemeinhin erst mit der wirklichen praktischen Erfahrung ein.

Projektvorlagen für Web-Entwickler

Klammern wir also zunächst einmal MVC aus. Was stellt uns VS 2012 denn so an Vorlagen bereit? Ein Klick auf „Datei -> Neu -> Webseite“ bringt ein wenig Klarheit:

Abb. 1: Web-Projektvorlagen

Im Gegensatz zu .NET Framework 4 fällt vor allem auf, dass die Vorlage für „ASP.NET Dynamic-Data-LINQ to SQL-Website“ nun fehlt. Hier soll offensichtlich nur noch „ASP.NET Dynamic Data Entities-Website“ genommen werden. Ich selbst wähle erstmal die Vorlage „Website für ASP.NET-Web-Forms“ aus. Kaum dass das Projekt geöffnet ist, wähle ich meine neue Lieblingsfunktion aus, um mir einen Überblick zu verschaffen, den PageInspector:

Abb. 2: Page Inspector auswählen

Drücke ich nun F5, wird mein Bildschirm zweigeteilt und ich erhalte im VS eine Debug-Möglichkeit.

Abb. 3: PageInspector in Aktion

Das Schöne ist, wie bereits an anderer Stelle erwähnt, dass ich nun im rechten Bereich Änderungen vornehmen kann. Wenn ich dann Strg + Alt + Enter drücke (was leider in meiner VM nicht geht) oder im PageInspector auf den entsprechenden Hinweis klicke (was in meiner VM geht), aktualisiert sich der im PageInspector gezeigte Inhalt. Markiere ich umgekehrt irgendwas im PageInspector wird mir im Quellcode das Äquivalent markiert. Zusätzlich hat der PageInspector die Developer-Tools des IE integriert, sodass ich wirklich keinen Browser mehr brauche.

Multi-Browser-Debugging

Irgendwann wird es natürlich Zeit, sich das Ergebnis der eigenen Programmierkunst auch mal in „echten“ Browsern anzusehen. Dazu konnte man auch bisher schon mehrere Browser im Dialog „Browserauswahl“ (Rechtsklick auf ein Web-Projekt -> Browserauswahl) definieren, indem man die Strg-Taste beim Anklicken der verfügbaren Browser benutzt und mehr als einen als Standard setzt. Wofür das im alten VS gut gewesen sein soll, hat sich mir immer schon verschlossen, denn es startete eigentlich immer einfach irgendeiner der Ausgewählten. Jetzt ist das anders. Der Run-Button zeigt nun den Text „Multiple Browsers“ und nach Betätigung von F5 erscheint folgender Dialog:

Abb. 3: Browser-Auswahl-Dialog

Jetzt macht die Option endlich Sinn. Bei mir startet übrigens immer auch der PageInspector, was ich ein wenig seltsam finde, wenn ich ihn doch explizit ausgeschaltet habe. Was im Übrigen auch das 2012er nicht mitbekommt ist, wenn man ein Nicht-IE-Fenster schließt. Die Debug-Session bleibt fröhlich aktiv. Das Beenden eines IE-Fensters bekommt er artig mit. Schade! Andererseits kann man mittlerweile wirklich mit dem IE debuggen.

Projektstruktur

Aber was ist eigentlich alles in einem Standard-Web-Projekt mit an Bord? Zwei Stellen sollte man dafür untersuchen. Zuerst sehe ich mir die Verweise an, die die Projektvorlage standardmäßig einbindet:

Abb. 4: Standard-Verweise

ASP.NET-Recken werden nun verwundert die Stirn in Falten legen. Woher kommt denn der bin-Ordner? Ja, ganz recht. Der bin-Ordner ist jetzt immer Bestandteil von Webseiten. Ich finde das nur konsequent, da er implizit ja eigentlich immer schon da war. Ohne System.Web ging auch in der alten Welt nicht viel.

Mit an Bord sind ANTLR, jQuery und WebGrease. Gerade das letztere stellt für mich noch ein kleines Rätsel dar. Grease heißt sowas wie Schmiermittel und sieht man sich den Namespace im Objektkatalog an, sieht man Themen, wie Minification, CSS-Parsing und Encoding. Ich gehe derzeit davon aus, dass es sich hier um die Basis so einiger noch zu erwähnender Neuerungen handelt. Leider schweigt sich die MSDN dazu komplett aus und die Code-Dokumentation scheint leer zu sein. Jedenfalls bringt WebGrease auch die WG.exe.refresh mit.

Die WG.exe selbst findet sich nach einer Suche erstmal in „C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Packages\WebGrease.1.0.0\lib“ und sie wird in den Projektordner mit übernommen. Ruft man sie in einem CommandLine-Fenster auf, gibt sie ein wenig mehr über ihre Funktion preis:


Usage:
 webgrease.exe <operation switch> -c=<configFile> -type=<configType>
 OR
 webgrease.exe <operation switch> -in=<inputPath> -out=<outputPath>
 Switches
 -m : Minifies files in the set.
 -v : Validates files in the set.
 -s : Sprites any background images in css files.
 -a : Auto names output files (if the -out parameter is a Directory and not a file).
 -b : Bundles all input files into a single output file. Required if the
 -out parameter is a file.
 Parameters
 -c : Specify a config file. All other parameters (except type) are ignored if a a config file is specified.
 -type: specifies a config type name to use for settings.
 -in : Input path. This can be a single file or a folder. If it is a folder, all files within will be processed.
 -out : Output path. This can be a folder or a single file. If this is a single file, the -b switch must be set to enable bundling.
 -tokens : Path to the tokens file. Used for expansion of tokens with the -e switch.
 -images : Path containing images for CSS spriting. Required when the -s switch is set.

Weiter geht die Entdeckungsreise im Ordner „App_Code“. Hier findet man zunächst die AccountHelper.cs. Sie zeichnet sich zunächst vor allem durch eine erfrischende Abwesenheit von Kommentaren aus (ich hab‘ schon immer gewusst, dass die HTML-lastigen Teile des Microsoft-Teams Code-Kommentare als überflüssig erachten!). Letztlich handelt es sich um eine statische Klasse, die uns einen Wrapper für das Umwandeln in JSON gibt (keine Ahnung, warum) und in einer simplen „Require“-Methode etwas in meinen Augen Sinnloses tut.

Sehr viel aufschlussreicher kommt da schon die andere Datei daher: BundleConfig.cs. Sie beinhaltet zunächst eine einzige statische Methode RegisterBundles. Diese Datei steuert im wesentlich die Art und Weise, wie das neue automatische Bundling vorgehen soll. Aufgerufen wird diese Methode durch eine Zeile in Application_Start innerhalb der Global.asax:

void Application_Start(object sender, EventArgs e)
{
    BundleConfig.RegisterBundles(BundleTable.Bundles);
}

Letztlich sorgt die BundleConfig nun dafür, dass man selbst sehr fein einstellen kann, welche Bundles es gibt und welche Dateien jedes Bundle beinhalten soll. Es gibt nun benannte Bundles, die Microsoft in einem virtuellen Verzeichnis „~/bundles/“ eingliedert. Man kann trotzdem noch „~/Content/css“ schreiben, erhält aber lediglich die „site.css“. Hier ist nun Vorsicht angebracht, denn anders, als in der Preview schaltet dies das automatische Packen anhand der Dateiendung aus. Ich habe versuchsweise eine „Test.css“ in den Content-Ordner gebracht. Ohne die BundleConfig anzupassen, sind die Styles nicht angekommen. Andererseits ist diese Vorgehensweise eigentlich noch besser, als die bisher gezeigte, denn erstens sorgt sie für einen verantwortungsvolleren, weil bewussten, Umgang mit den Styles und zweitens kann man nun auch ordnerübergreifend bundlen.

Der zweite Bereich, den man sich mittlerweile angucken sollte, ist Nuget. Ein Klick auf „Website -> NuGet-Pakete verwalten“ offenbart, dass nicht weniger als 12 Pakete bereits Bestandteil der Standard-Vorlage sind. Die bereits besprochenen DLLs sind ebenfalls per NuGet dazu gekommen. Ist das nun gut oder schlecht? Einige Entwickler sind nach wie vor kein großer Freund dieses Paket-Mechanismusses. Egal mal wie, es sorgt dafür, dass das ASP.NET-Team zukünftig Updates unabhängig vom VS-Release-Zyklus bereit stellen kann und das ist erstmal jedenfalls nicht schlecht. Der Preis dafür bleibt eigentlich der gleiche, wie bisher: Bereits die RC-Release listet erstmal 5 Pakete als updatewürdig. Interessant übrigens auch: Das „Microsoft ASP.NET Web Optimization Framework“ ist noch als Prerelease gekennzeichnet.

Bundling

Im vorrangegangenen Abschnitt war bereits viel über Bundling enthalten, aber das reicht halt noch nicht. Viel wichtiger ist nun der Aufruf des Bundlings. Wer meinen Preview-Artikel gelesen hat, der hat auch meine Vermutung mitbekommen, dass der komplizierte Aufruf der Bundlings in einem HtmlHelper enden würde. Ich hatte unrecht, aber einfacher wurde es trotzdem. Das ASP.NET-Team hat neue Helper-Klassen erzeugt. Am schnellsten kann man sich hier in der Site.master einen Überblick verschaffen. Sie ruft das Bundling im Standard wie folgt auf:

<asp:PlaceHolder runat="server">
    <%: Styles.Render("~/Content/themes/base/css", "~/Content/css") %>
    <%: Scripts.Render("~/bundles/modernizr") %>
</asp:PlaceHolder>

Es gibt nun 2 neue Helper-Klassen „Styles“ und „Scripts“. Sie befinden sich im Namespace „System.Web.Optimization“. Der Styles-Helper erfordert als Übergabe einen in der BundleConfig definierten Pfad, der dort als StyleBundle (im gleichen Namespace definiert) angegeben wurde. Analog dazu besteht eine Abhängigkeit zwischen Script und ScriptBundle. Dieses Zusammenspiel aus Aufruf und BundleConfig ist sehr logisch und einfach verständlich. Passt.

Was übrigens auch noch geändert wurde: Das Bundling findet nun nur noch dann statt, wenn in der web.config der Debug-Schalter nicht gesetzt ist und man kann über das Interface IBundleTransform eigene Bundling-Mechanismen definieren und einbinden. Scott Hanselman ist in seinem Blog-Artikel darauf eingegangen.

Editoren

Einige werden sich bereits vor mehreren Absätzen gedacht haben: „Wann kommt der Typ denn nun zum eigentlich Wichtigen?“. Jetzt ist es soweit. Zunächst eine kleine Einführung: Das Thema Code-Editoren im Web-Umfeld ist fast schon eine Glaubensfrage. Manche schwören hier auf möglichst einfache Tools, wie das Notepad oder das mit dem angehängten „++“. Wiederum andere nutzen ausschließlich Dreamweaver oder andere mehr WYSIWYG-Tools. Microsoft hat hier eine lange und teilweise konfuse Tradition hinter sich, die letztlich im Visual Studio endete. Allen Tools ist jedenfalls gemein, dass sie einen schmalen Grat zwischen Komfort und Gängelung beschreiten. In meinen Augen stellt VS 2012 hier die derzeitige Spitze der Nahrungskette dar.

Beginnen wir mit dem HTML-Editor. Was ist hier wichitg? Erstens muss man bequem schreiben können, zweitens muss der Editor möglichst viel über Web-Standards wissen, um uns Unterstützung zu bieten und drittens muss er sich darüber im Klaren sein, dass man manchmal tricksen muss, um ein Produkt wirklich einigermaßen überall zum Laufen zu bekommen. Gerade im letzten Punkt hat MS bis zum VS 2010 ein wenig gepatzt. Das ist nun vorbei. VS 2012 erkennt nun an, dass es oftmals Tricks geben muss, und meckert nicht ständig wegen irgendwelcher Standard-Verletzungen herum. In HTML selbst war das eigentlich nicht das Problem, aber bei Einsatz von Inline-CSS nervte es doch sehr. Das ist nun vorbei. Meckern tut der Editor (oder eigentlich der HTML-Parser) nur dann, wenn man etwas wirklich böses tut (HTML5, table mit with attribut) und das ist auch richtig so.

Bequem schreiben wurde nun wahrlich hervorragend umgesetzt. Am besten lässt sich das am Beispiel der automatischen End-Tags zeigen. Egal, ob man das End- oder Starttag umbennent: das zugehörige Schwester-Tag wird immer mit umbenannt. Wie viele Stunden mir das in Summe eingespart hätte, kann ich nicht genau beziffern. Weniger graue Haare hätte ich aber glaube ich schon.

Das Wissen über die Webstandards war eigentlich schon länger da. Jetzt aber hält sich Microsoft wirklich daran und schlägt teilweise weniger Unsinn vor. Das sind aber Dinge, die jeder erstmal ausprobieren sollte.

So richtig lustig wird es beim CSS-Editor. Er sieht erstmal ziemlich harmlos aus, hat es aber faustdick hinter den Ohren.

Zunächst einmal gibt es nun eingebaute echte IntelliSense für Dinge, wie Farben und Schriften:

Abb. 5: IntelliSense für CSS-fonts
Abb. 6: IntelliSense für Farben

Allein die Abbildung 6 beinhaltet einiges an coolen Dingen. Zum einen ist es, wie gesagt, echtes IntelliSense und nicht irgendein aufpoppender Dialog. D.h., der Arbeitsfluss wird nicht unterbrochen. Zum anderen kann man direkt mit Transparenzen arbeiten und unten rechts über die Pipette beliebige Screen-Pixel aus Vorlage nehmen. Viel wichtiger aber: Die Leiste am oberen Rand zeigt u.a. alle in der CSS-Datei bereits genutzten Farbcodes an. Das nenne ich mal Mitdenken!

Aber es wird noch besser. Der CSS-Editor kennt regions:

/*#region test */

/*#endregion*/

und er erkennt automatisch Schachtelungen und rückt entsprechend ein:

.TestClass {
color: #ff006e;
}

    .TestClass div {
    }

Wer schon einmal komplexere CSS-Dateien zu verwalten hatte, wird verstehen, warum ich das so hervorhebe.

Noch deutlicher tritt die neue Philisophie bei MS hervor, wenn man sich im CSS-Editor mal Eigenschaften, wie „border-radius“ ansieht. CSS-Entwickler wissen, dass man hier auf die einzelnen Renderer eingehen muss, damit runde Ecken nicht nur in einem Browser auftauchen. Microsoft unterstützt uns hier nun wunderbar. Einfach mal „border-radius“ tippen und zweimal Tab drücken:

-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px;

Es stimmt. VS generiert tatsächlich diese 3 Attribute automatisch und da es sich um nichts anderes, als ein Codesnippet handelt, können wir nach erneutem Tab einfach den Wert für alle 3 Einstellungen ändern.

Was noch?

Während meiner Tests sind mir noch andere kleinere Funktionen ins Auge gefallen. Kann sein, dass sich hier Ähnliches bereits in früheren VS-Versionen fand, ich es aber dort nie gesehen habe.

Im Menu „Website“ fällt mir der Punkt „ASP.NET-Ordner hinzufügen“ auf:

Abb. 7: Web-Ordner-Menu

Finde ich extrem praktisch, weil ich immer nicht weiß, wie genau die Konvention für diese Ordner lautet.

Es gibt neue Elemente, die einem Projekt hinzugefügt werden können. Neben anderen ist mir der „AJAX-aktivierte Webdienst“ aufgefallen, der einem die Möglichkeit bietet, sehr schnell REST-Services einzubinden. Ich weiß noch nicht so ganz, ob ich das gut finden soll, aber es erleichtert einem bei verantwortungsvollem Umgang mit dem Thema sicherlich die Arbeit.

Viele Ideen des MVC-Teams sind nun im ASP.NET-Team angekommen, was nicht weiter verwundert, wenn man weiß, dass MS hier einiges an Konsolidierungs- und Organisations-Arbeit investiert hat. Der Ordner „Account“ mit den dazugehörigen ASPX-Dateien erinnert stark an die View-Ordner in den MVC-Projektvorlagen. Gut zu erkennen ist diese neue Einheit auch an den nahezu gleichen Layouts der Beispiel-Seiten.

Auf den ersten Blick relativ wenig (ich glaube sogar gar nichts) hat sich an Themen, wie Toolbox-Elemente, Publishing und Projekt-Eigenschaften geändert. Mit anderen Worten: der Fokus der Neuigkeiten liegt auf der Bedienung und den Standards.

Resumé

Treue Leser meines Blogs wissen, dass ich wenig von dem teilweise vorherrschenden Neuerungswahn halte und eher ein Verfechter der ständigen Verbesserung bereits etablierte Techniken bin. In meinen Augen ist es Microsoft gelungen, dies im Webbereich des neuen VS wunderbar durchzuführen. Ich freue mich auf das endgültige Release und werde allein für die Neuerungen im Web-Bereich sofort eine Installation auf meinen Rechnern durchführen.

2 Antworten auf „Visual Studio 2012 RC – Web-Tools“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.