Visual Studio 14 CTP angetestet

 

Ich hatte viel zu lange keine wirkliche Zeit, mir die CTP für das kommende VS 14 anzusehen. Inzwischen ist die 3. CTP-Version draußen und in gewohnter Manuier wird ein Blick drauf geworfen.

Screencast

(in Arbeit)

Links

Englische Version der News im MS Support-Bereich

Anleitung zur Nutzung eines fertigen Azure-Images zum Probieren

Probieren

Wer nicht gleich das 4 GB große ISO laden und dann installieren möchte, der kann auch ein fertiges in Azure nutzen. Da nicht jeder einen solchen Account oder Lust/Zeit hat, sich das ganze Setup anzutun, der kann sich hier ein wenig nach neuen Features umsehen.

Kleinere Verbesserungen

Vorweg seien erstmal ein paar Kleinigkeiten erwähnt, die trotzdem gleich mal getestet werden können. Da wäre zunächst einmal die Integration von hochauflösenden Symbolen für Toolbars usw. Das ist ganz sinnvoll, wenn die heute immer gängigeren hochauflösenden DPI-Monster von Monitoren zum Einsatz kommen.

Der Designer des 2012-Updates hat offenbar seine Wette verloren und so wurde nun das Menu wieder standardmäßig in Normalschreibweise integriert und „Blue“ ist das neue Standardtheme:

Abb. 1: Back to the roots (rechts VS 2014)
Abb. 1: Back to the roots (rechts VS 2014)

Das gesamte Studio soll sich nun außerdem auf Touch-Displays sauber bedienen lassen. Getestet habe ich das noch nicht, es soll aber vor allem Probleme beim Scrollen, mit Multi-Touch-Gesten usw. beheben.

Roslyn

Eine der am heißesten erwarteten Änderungen betrifft sicherlich die inzwischen unter Git gehostete neue Compiler-Plattform „Roslyn“. Achtung! Das Roslyn auf Git gehostet ist, bezieht sich meinen Nachforschungen zufolge nur auf den Quellcode. Die zentrale Anlaufstelle ist immer noch Codeplex. Einige Medien haben sich hier missverständlich ausgedrückt. Die Möglichkeiten von Roslyn reichen weit. Was uns im VS erwartet, sind vor allem allerhand Helferlein, die durch ständige Analyse des Quellcodes sinnvolle Vorschläge unterbreiten können. Sowas war bisher fast ausschließlich in Tools, wie ReSharper integriert und arbeitete eher auf komplexen synthaktischen Regeln. Das kostete vor allem Performance wovon ReSharper-Benutzer ein leidvolles Liedchen singen können. Roslyn arbeitet komplett anders und hat den gleichen Einblick in den Quellcode und die Abhängigkeiten und semantischen Zusammenhänge, wie der jeweilige Sprachcompiler – weil es nämlich der neue Compiler werden soll.

Die Idee ist ziemlich neu und geht weit über Themen, wie Reflection hinaus. Ich beschäftige mich selbst gerade erst mit den sich ergebenden Möglichkeiten und gehe daher noch nicht näher darauf ein.

Licht an

Etwas, das bisher auch nur Tools, wie ReSharper u.a. boten, sind extrem nützliche SmartTag-Helfer bei alltäglichen Problemen. Ein einfaches „Strg“ + „.“ und dann Enter hilft hier aus der Patsche:

Abb. 2: Smart-Tags erweitert
Abb. 2: Smart-Tags erweitert

ReSharper ist hier noch etwas weiter, weil man bei Klassen außerhalb der aktuellen Assembly keinen Verweis auf das Projekt braucht. Das kann das Lämpchen noch nicht, aber es ist auf jeden Fall ein Schritt in die richtige Richtung.

In Abb. 2 ist auch schön zu erkennen, wie die SmartTags (und zwar alle) inzwischen eine Vorschau vorgeschlagener Aktionen am rechten Rand des Kontextmenus anzeigen.

Analyzers

Ich bin noch ein wenig verunsichert, was das Element „Analyzers“ unterhalb eines Projkektes genau bedeuten soll:

Abb. 3: Analyzers
Abb. 3: Analyzers

Ich habe die Vermutung, dass es hier vor allem um eine Integration für Web und Phone geht. Es könnten hier Performance- und andere Analyzer integriert werden. Im Moment kann man das Element rechts anklicken und bekommt dann eine Add…-Auswahl ohne Inhalt. Eine andere hier erscheinende Funktion namens „Open Rule Set…“ bringt einen direkt zu den Einstellungen der aktuell auf dem Projekt eingestellten Codeanalyse. Ich kann mir nicht vorstellen, dass das eine große Menge an Benutzern gefordert hat, aber es wird schon seinen Sinn haben.

Window Layouts

Window Layouts sind eigentlich nichts neues im VS. Seit 2012 kann man bereits beobachten, dass ein Studio zwischen dem Aussehen im Debug- und im Design-Mode unterscheidet. Dies ist im Prinzip die Basis für die neuen Window Layouts im Menu „Window“:

Abb. 4: Window Layouts
Abb. 4: Window Layouts

Man kann über „Save Window Layout“ beliebige Anordnungen und Einstellungen innerhalb des VS speichern und diese dann jederzeit anwenden. Ich gehe davon aus, dass diese Einstellungen zwischen Rechnern gesynched werden, wenn man sich mit einer Live-ID anmeldet. Das ist ungemein praktisch und zielt darauf ab, dass immer mehr Leute zwischen den völlig unterschiedlichen Auflösungen von Desktop und Mobil unterscheiden müssen. Gute Idee.

Shared Project

Zunächst hatte ich nicht verstanden, was mir ein neuer Projekttyp namens „Shared Project“ sagen soll. Erst nach einigem Überlegen und Probieren bin ich der Sache auf die Spur gekommen. Hier erstmal der Eintrag im „Add New Project“-Dialog und der entsprechende Solution Explorer:

Abb. 5: Shared Project hinzufügen
Abb. 5: Shared Project hinzufügen
Abb. 6: In der Solution + Kontextmenu
Abb. 6: In der Solution + Kontextmenu

In Abb. 6 sieht man, dass man ein Shared Project nicht bauen kann. Genau genommen, hat es nicht einmal eine Property Page (ein Klick auf Properties öffnet nur das Standard-Eigenschaften-Dock und dort kann man nur den Standard-Namespace ändern. Ich kann nun über „Add“ beliebige Elemente zu einem Shared Project hinzufügen.

Anstatt nun aber diesen Code einfach nur zu bauen, kann man in anderen Projekten der gleichen Solution auf dieses Shared Project verweisen:

Abb. 7: Referenz auf Shared Project
Abb. 7: Referenz auf Shared Project
Abb. 8: Referenz auf Shared Project
Abb. 8: Referenz auf Shared Project

Wie man in Abb. 7 sieht, geschieht dies über einen neuen Quelltyp für Referenzen. Es passiert hier offensichtlich nichts anderes, als das ein symbolischer Link all der Elemente aus dem Shared Project in das andere Projekt übertragen wird, sodass dieses dann mit den jeweils eingestellten Optionen das Bauen übernimmt. Im Unterschied zu Portable Libraries bestimmte ich also auf dem Shared Project nicht alle kompatiblen Ziel-Frameworks, sondern sammele einfach nur Code, den andere Projekte dann referenzieren können – wie gesagt eine Ablösung des Symbolic-Link-Patterns basierend auf Solution Folders.

Ein Blick in den Object Browser zeigt das noch mal aus einer anderen Sicht:

Abb. 9: Shared Project im Object Browser
Abb. 9: Shared Project im Object Browser

Der Namespace SharedElements ist Bestandteil der Assembly MyLogic. So richtig interessant wirds, wenn man nun das SharedAssemblyInfo-Pattern aus einem meiner letzten Beiträge mit einem Shared Project umsetzt. Der Vorteil ist, dass es nun reicht, einfach eine Shared-Project-Referenz zu setzen. Die SharedAssemblyInfo wird dann von allein gefunden.

Kein SlowCheetah-Ersatz!

Als echtes Problem stellt sich für mich dar, dass Sayed Ibrahim Hashimi die Weiterentwicklung von SlowCheetah nicht weiter betreiben will. Ich habe natürlich an der Suggestion für ein entsprechendes Feature in VS 2014 teilgenommen. Die vorliegende CTP zeigt allerdings keinerlei Anzeichen dafür, dass MS hier eine Lösung präsentieren wird. Man kann die Extension auf dem offiziellen Gallery-Weg auch nicht mehr im 14er Studio installieren. Dieses Problem kann in den meisten mir bekannten Projekten zu einem echten Problem werden. Mal schauen, was hier passiert.

ASP.NET vNext

Dieses Thema ist zu riesig, um es in einem kleinen Beitrag über VS 14 einzupacken. Nur so viel: Vergesst alles, was Ihr über MVC zu wissen glaubtet. Na ja, zumindest fast. Ich muss erst selbst die Zeit finden, mich mit den neuen Ideen anzufreunden und die Implikationen in Projekten zu erkennen. Man sollte sich nur nicht wundern, wenn man in einem vNext-Projekt den Überblick und die gewohnte Sicherheit verliert.

Die gute Nachricht ist die, dass man vNext nicht sofort einsetzen muss. Das MVC5-wird genauso weiter unterstützt, wie die 2012er-Projekttypen auch.

Fazit

Es gibt viel Neues, aber wie in den letzten Updates schon zur Regel geworden, zum größten Teil unter der Haube. Elemente, wie Roslyn und Shared Project werden Einfluss auf unsere tägliche Arbeit haben, finden aber i.d.R im Hintergrund statt. ASP.NET vNext gehört eigentlich nicht zum Visual Studio und hat mit diesem also erstmal nichts zu tun. Das Gute an diesen „vorsichtigen“ Updates ist, dass man relativ bedenkenlos umsteigen kann.

Gerade der letzte Satz könnte bei einer fehlenden Alternative zu Slow Cheetah allerdings komplett ins Gegenteil verkehrt werden. Wir bleiben dran.

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.