{"id":6455,"date":"2015-11-11T15:10:21","date_gmt":"2015-11-11T14:10:21","guid":{"rendered":"http:\/\/www.centigrade.de\/blog\/?p=6455"},"modified":"2015-11-11T15:19:26","modified_gmt":"2015-11-11T14:19:26","slug":"viele-kleine-verbesserungen-neuerungen-in-visual-studio-2015","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/viele-kleine-verbesserungen-neuerungen-in-visual-studio-2015\/","title":{"rendered":"Viele kleine Verbesserungen \u2013 Neuerungen in Visual Studio 2015"},"content":{"rendered":"

Visual Studio 2015 h\u00e4lt einige Neuerungen f\u00fcr Entwickler bereit. Stellt sich die Frage: Welche dieser Neuerungen sind wirklich geeignet, einem das Leben als Entwickler einfacher zu machen? Und worauf kann man eher verzichten?<\/p>\n

Visual Studio 2015 kommt ohne\u00a0„Killer“-Feature (aus)<\/h3>\n

Zun\u00e4chst sollte gesagt sein, dass mit der neuen Visual Studio Version kein neues Feature eingef\u00fchrt wurde, das superinnovativ ist und welches die Leute komplett begeistert.
\nVisual Studio 2015 benutzt zwar den neuen Roslyn Compiler<\/a>, der etwas schneller ist und durch den manche Features erst m\u00f6glich werden, jedoch ist dies f\u00fcr mich ja nur indirekt erkennbar und f\u00e4llt daher beim ersten Hinsehen nicht so stark auf.\u00a0Es wurden aber auch viele kleine \u00c4nderungen und Verbesserungen vorgenommen, welche mir als Entwickler direkt ins Auge springen, und die in der Summe die Arbeit mit Visual Studio und Blend durchaus vereinfachen werden.<\/p>\n

Intuitiverer Umgang mit Breakpoints<\/h4>\n

Angefangen bei den Breakpoints und den M\u00f6glichkeiten dort Bedingungen und Aktionen zu definieren: Von der Funktion her hat sich nicht viel getan, denn Bedingungen f\u00fcr Breakpoints konnte ich bislang auch schon einf\u00fcgen, jedoch ist diese Option nun direkt beim Mouseover verf\u00fcgbar, statt wie bisher \u00fcber einen Rechtsklick. Das h\u00f6rt sich nat\u00fcrlich nach einer v\u00f6llig banalen \u00c4nderung an, jedoch f\u00fchlt sich das Ganze dadurch einfacher und intuitiver an als zuvor.<\/p>\n

Eine weitere \u00c4nderung bei den Breakpoints findet sich beim Debuggen. Wenn ein Programm an einem Breakpoint anh\u00e4lt dann bekomme ich nun die Zeit angezeigt, die seit dem letzten Breakpoint verstrichen ist. Dies kann besonders bei kleineren Performance-Fragen hilfreich sein, da ich sehr einfach nachvollziehen kann wo die meiste Zeit zwischen zwei Haltepunkten verbraucht wurde ohne gleich eine Performance-Analyse starten zu m\u00fcssen.\"Elapsed-Time-At-Breakpoints\"<\/p>\n

Code Editor \u00fcberarbeitet<\/h4>\n

Im Code Editor werden nun auch die Informationen des CodeLens Features angezeigt. CodeLens gab es zwar schon in Visual Studio 2013, jedoch bisher nur in der Ultimate Edition. In der neuen Version soll es nun bereits in der Professional Edition verf\u00fcgbar sein.\u00a0Oberhalb einer Funktion oder Eigenschaft wird dann die Anzahl der Referenzen auf diese angezeigt, die per Mausklick n\u00e4her untersucht werden k\u00f6nnen. Au\u00dferdem sehe ich in welchen UnitTests die Funktion verwendet wird und kann diese auch direkt laufen lassen ohne in den Test-Explorer wechseln zu m\u00fcssen.<\/p>\n

An dieser Stelle wurde auch die Team Activity View \u00fcberarbeitet. Diese zeigt den Codeverlauf nun in einer \u00fcbersichtlichen Grafik an. So erkenne ich nun sofort welcher Entwickler wann \u00c4nderungen an dieser Funktion oder Klasse gemacht hat und ich kann eine fr\u00fchere Version auch direkt aus dem Code heraus mit der aktuellen Version vergleichen.<\/p>\n

Viele dieser Funktionalit\u00e4ten sind nicht neu, sie sind nun aber \u00fcbersichtlicher und die gew\u00fcnschten Informationen sind einfacher zug\u00e4nglich als dies vorher der Fall war. Somit ist es f\u00fcr mich nun viel leichter diese Features effektiv zu nutzen.
\n\"Function-References-Overview\"<\/p>\n

<\/h2>\n

Besser gut kopiert als schlecht erfunden<\/h3>\n

Nach diesem Motto hat sich Microsoft bei einigen anderen Tools Anregungen geholt und versucht deren Funktionalit\u00e4t mit in Visual Studio zu integrieren.\u00a0So l\u00e4sst sich bei WPF Anwendungen zum Beispiel der Visual Tree anzeigen und die Eigenschaften einzelner Elemente lassen sich zur Laufzeit \u00fcber den Live Property Explorer manuell ver\u00e4ndern. F\u00fcr solche Zwecke habe ich bislang das Tool Snoop <\/a>benutzt, nun ist diese M\u00f6glichkeit aber schon direkt in Visual Studio mit dabei. Wenn ich im Live Visual Tree ein Element selektiert habe, kann ich jetzt sogar an die entsprechende Stelle im Quellcode springen, an welcher das Element definiert ist. So finde ich die gesuchte Stelle einen Schritt schneller als zuvor.<\/p>\n

Auch neu ist die kleine Gl\u00fchbirne die immer dann am Rand auftaucht, wenn Visual Studio Verbesserungen im Code vorschl\u00e4gt. Hier hat sich Microsoft an der allseits beliebten Extension ReSharper<\/a> orientiert, welche f\u00fcr mich als Entwickler aus dem Alltag nicht mehr weg zu denken ist.\u00a0Neu ist hier, dass mir nun eine Vorschau der vorgeschlagenen \u00c4nderungen angezeigt wird, sobald ich mit der Maus \u00fcber einen Vorschlag fahre. Dies ist bei komplexeren \u00c4nderungen sehr hilfreich, da ich so schneller verstehe was nun eigentlich passiert. Hier sagt ein Bild einfach mehr als tausend Worte. Bei der Anzahl der vorgeschlagenen \u00c4nderungen h\u00e4ngt Microsoft dem Vorbild aktuell jedoch noch ein wenig hinterher. Deshalb werde ich meinen ReSharper <\/a>noch nicht sofort in den Ruhestand schicken und ich vermute mal, dass es vielen anderen Entwicklern \u00e4hnlich gehen wird. Wie sich diese Situation in der Zukunft entwickelt bleibt abzuwarten, jedoch gehe ich davon aus, dass Microsoft an dieser Stelle fr\u00fcher oder sp\u00e4ter noch etwas nachbessern wird.
\n\"Lightbulp-Preview\"<\/p>\n

IntelliTest \u2013 ein Ersatz f\u00fcr UnitTests?<\/h3>\n

Sehr interessant klingt auch das neue IntelliTest Feature, welches automatisch UnitTests f\u00fcr die aktuelle Klasse oder Funktion erzeugt. Dabei werden alle m\u00f6glichen Codepfade \u00fcberpr\u00fcft und dann entsprechende Testdaten erzeugt um eine maximale Codeabdeckung zu gew\u00e4hrleisten. Dies h\u00f6rt sich zun\u00e4chst zwar verlockend an, allerdings sollte man diese M\u00f6glichkeit mit Vorsicht genie\u00dfen. Der Code ist zwar abgedeckt, aber in den meisten F\u00e4llen sind die Testdaten rein zuf\u00e4llig gew\u00e4hlt und nicht richtig durchdacht, da dem Programm der logische Sinn hinter dem Test nicht bewusst ist. Au\u00dferdem ist es in vielen F\u00e4llen sinnvoll, dass ich die UnitTests schreibe bevor die zu testende Funktion richtig implementiert wird, damit potentielle Fehler schon direkt bei der Implementierung erkannt werden k\u00f6nnen. Zudem kann ich so gew\u00e4hrleisten, dass ich mit roten Tests beginne, was bei der Entwicklung von automatisierten Tests ein wichtiger Baustein in unserem Workflow bei Centigrade ist. Daher werde ich um das Schreiben eigener UnitTests wohl nicht herumkommen.<\/p>\n

Hilfreich kann das Feature f\u00fcr mich aber trotzdem sein, denn durch das Tool lassen sich m\u00f6glicherweise noch Testf\u00e4lle entdecken, an die ich vorher nicht gedacht habe.
\nEin Blick auf diese neue Funktion sollte sich also in jedem Fall lohnen. Leider wird dieses Feature wohl nur in der Enterprise Edition von Visual Studio 2015 verf\u00fcgbar sein und kann daher nicht von allen Entwicklern genutzt werden.<\/p>\n

Ein besseres Blend<\/h3>\n

In Blend haben sich auch einige Dinge zum Besseren ge\u00e4ndert. Denn Blend benutzt nun ebenfalls die Visual Studio Shell. Dies f\u00fchrt dazu, dass das visuelle Erscheinungsbild nun etwas st\u00e4rker an Visual Studio erinnert. Auch der Projektmappen-Explorer wurde durch die Visual Studio Variante ersetzt und l\u00e4sst sich nun einfacher benutzen als zuvor.\u00a0Die gr\u00f6\u00dfte \u00c4nderung d\u00fcrfe hier allerding der neue Code-Editor sein, welcher nun der gleiche wie in Visual Studio ist. Dies erm\u00f6glicht mir nicht nur eine bessere \u00dcbersicht, sondern bietet auch Code-Highlighting und IntelliSense, was mir die Bearbeitung von Code-Dateien in Blend um ein Vielfaches angenehmer macht. Dieses Feature ist ebenfalls nicht wirklich neu, denn in Visual Studio selbst gab es diesen Code-Editor vorher auch schon. Aber wenn ich diesen mit dem alten Editor von Blend vergleiche wird schnell klar, dass man hier einen riesen Sprung nach vorne gemacht hat was die Usability angeht.<\/p>\n

Ebenfalls ge\u00e4ndert wurde die Peek-M\u00f6glichkeit, die es mir erlaubt XAML-Steuerelemente und Ressourcen in dem Kontext, in welchem sie verwendet werden, direkt anzuzeigen und zu bearbeiten. Wenn ich beispielsweise die Zuweisung einer Ressource angeklickt habe und Alt + F12 dr\u00fccke so erscheint ein kleines Fenster in dem ich diese Ressource sehe und direkt bearbeiten kann. Angezeigt wurde dieses Fenster auch schon vorher, jedoch war es bislang schreibgesch\u00fctzt und ich konnte darin keine \u00c4nderungen vornehmen.
\n\"Peek-Window\"<\/p>\n

Im XAML selbst gibt es auch noch eine ziemlich simple \u00c4nderung, bei der die Meinungen in der Entwickler Gemeinde jedoch stark auseinander gehen. Es ist ab sofort n\u00e4mlich m\u00f6glich, in XAML-Dateien Regions einzuf\u00fchren, wie man sie auch schon aus C# kennt. Ich pers\u00f6nlich finde dieses Feature klasse, denn gerade bei gro\u00dfen Dateien hatte ich bisher oftmals das Problem, dass diese viel zu un\u00fcbersichtlich waren. Durch die Regions kann ich nun etwas mehr Ordnung hineinbringen und meinen XAML-Code lesbarer gestalten. Es gibt aber auch Software Engineers, die diese M\u00f6glichkeit furchtbar finden. Unter anderem auch deshalb, weil sich die Regions hier nicht sehr intuitiv schreiben lassen da man sie in einen Kommentar einbetten muss.<\/p>\n

Ein weiteres kleines Feature, das jedoch gro\u00dfe Auswirkungen hat, findet sich beim Wechsel zwischen Visual Studio und Blend. Bisher wurde ich jedes Mal, wenn ich zwischen den Anwendungen gewechselt habe, gefragt, ob die \u00c4nderungen aus dem anderen Programm \u00fcbernommen werden sollen. Nun kann ich in einer Checkbox einen Haken setzen und Blend merkt sich dann diese Entscheidung.<\/p>\n

Eine wichtige Neuerung ist auch das neue Timeline-Tool, welches eine genaue Performanceanalyse der Benutzeroberfl\u00e4che erm\u00f6glicht und das bisherige XAML UI Responsiveness Tool abl\u00f6sen wird. Mit dem neuen Tool kann ich nun genau sehen, wo im UI-Thread Zeit aufgewendet wird und sich gegebenenfalls Engp\u00e4sse befinden. Die Benutzung dieses Tools finde ich einfach und intuitiv. Wenn ich eine Diagnose-Session starte, werden w\u00e4hrend der Laufzeit entsprechende Daten wie CPU- und GPU-Auslastung oder auch die Bildrate gesammelt. Die Anzeige dieser Daten ist sehr \u00fcbersichtlich, sodass ich ohne Probleme die relevanten Aktionen herausfiltern und somit genau sehen kann, was in welchem Schritt passiert.<\/p>\n

Der Haken an dieser Sache ist jedoch, dass sich das Ganze nur auf Systemen mit Windows 8.1 oder h\u00f6her ausf\u00fchren l\u00e4sst. Entwickler, die noch unter Windows 7 entwickeln, m\u00fcssen auf dieses Tool leider verzichten.
\n\"Timeline-Tool-Analysis\"<\/p>\n

Fazit:<\/h2>\n

Mit Visual Studio 2015 hat Microsoft viele Kleinigkeiten verbessert und optimiert und so den Umgang mit dem Programm ein St\u00fcck komfortabler gemacht.\u00a0Gerade im t\u00e4glichen Gebrauch wird man sich sehr schnell an die neuen Features gew\u00f6hnen und eine bessere Alltagsperformance erreichen.\u00a0Und auch wenn viele der \u00c4nderungen auf den ersten Blick vielleicht nicht als diese lang erwartete Superverbesserung erscheinen, so bin ich mir dennoch sicher, dass ich diese schon nach kurzer Zeit nicht mehr werde missen wollen.<\/p>\n

Ein wenig entt\u00e4uscht bin ich jedoch von der Tatsache, dass Visual Studio noch lange nicht alle Funktionalit\u00e4ten des ReSharpers <\/a>anbietet. Microsoft geht hier zwar in die richtige Richtung, bewegt sich aber nur in kleinen Schritten vorw\u00e4rts.<\/p>\n","protected":false},"author":44,"featured_media":0,"template":"","tags":[91],"class_list":["post-6455","blog","type-blog","status-publish","hentry","tag-blend-de"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/6455","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/44"}],"version-history":[{"count":0,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/6455\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=6455"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=6455"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}