Microsoft 10 Lutego ogłosił, że 7 Marca udostępni pełną wersję Microsoft Visual Studio 2017. Tego dnia, Microsoft nie tylko udostępni nową wersję naszego ulubionego IDE. To będzie także wielkie wydarzenie dla społeczności. Wystartuje dwudniowy event szkoleniowy, który będzie można oglądać online, prowadzony przez Julie Liuson (Visual Studio CVP), zobaczymy w nim także Scott’a Hanselman’a (VS i .NET PPM, tutaj jego blog), Miguel’a De Icaza (VS Mobile Distinguished Engineer) i Brian’a Harry’ego (VSTS CVP). Microsoft przygotował dla nas wiele nowości, takich jak udoskonalenia nawigacji po kodzie (znane z ReSharper’a), InteliSense, poprawkach kodu, refaktoringu i debugowaniu. Dostaniemy również lekki i modularny instalator, nowe możliwości przeglądania, edycji i debugowania kodu a także szybsze IDE od uruchomienia do zamknięcia. Marcowe wydarzenie będzie także świętowaniem 20 rocznicy Visual Studio (Pierwsze zostało wydane w Lutym 1997 roku).

A więc, jakie najciekawsze rzeczy moim zdaniem możemy znaleźć w Visual Studio 2017?

1. Konfiguracja stylu kodowania

Większość programistów, którzy nie kodują tylko w Visual Studio, powinna znać narzędzie EditorConfig. EditorConfig istnieje od lat, ale używanie go począwszy od VS 2010 do 2015 wymagało od nas instalacji extension’a. W kilku słowach, EditorConfig wymusza jednolitość stylu kodowania i pomaga deweloperom definiować i zarządzać spójnymi konwencjami i stylem kodu pomiędzy różnymi edytorami i IDE. Microsoft zaangażował społeczność EditorConfig aby rozszerzyć wsparcie dla ekosystemu Visual Studio i tak oto powstało .NET Code Style. Funkcjonalność tego narzędzia będzie jakby połączeniem narzędzia StyleCop i EditorConfig. Zespół EditorConfig dostarczył format pliku i jego składnie, który jest potem wykorzystywany do przestrzegania stosowania określonych w pliku konwencji przez programistę. Oto kilka przykładów użycia:

– ustawienie wcięć:

# Code files
[*.cs,*.csx,*.vb,*.vbx]
indent_size = 4

– wymuszanie korzystania z var dla typów wbudowanych:

# CSharp code style settings:
[*.cs]
csharp_style_var_for_built_in_types = true:error

w linijce csharp_style_var_for_built_in_types = true:error widzimy trueerror. Pierwsza wartość określa czy ta reguła ma być używana, druga wartość określa reakcję IDE i kompilatora. Mamy tutaj kilka możliwości: error – wyrzuci błąd podczas kompilacji, warning – jak sama nazwa wskazuje, dostaniemy ostrzeżenie podczas kompilacji, suggestion – IDE podkreśli nam kod na zielono, i none – nie zrobi nic.

editorconfig_usepatternmatch

 

Więcej na ten temat tutaj.

2. Odświeżony edytor JavaScript

Pamiętacie swoje próby tworzenia skryptów w ECMAScript 6/2015 (ES6) w VS 2015? A co powiecie o React’ie i JSX? Zapewnie nie zaliczacie tego do udanych doświadczeń. Podejrzewam nawet, że zrezygnowaliście z VS i przerzuciliście się na VS Code lub podobny edytor. Tworzenie Single Page Application (SPA) w VS było ciężkie ze względu na przestarzały edytor JS. W VS 2015 szczególnie brakło wsparcia dla kilku funkcjonalności ES6 takich jak import i eksport modułów. Deweloperzy byli prześladowani czerwonymi podświetleniami, informacjami o złej składni i zepsutym IntelliSense’m. Po sukcesie VS Code, VS 2017 zaadoptuje tą samą usługę języka JavaScript o nazwie „Salsa” która zapewnia szerokie wsparcie w takich technologiach jak ES6, ES7, JSX, Node i JsDoc!. Więcej na ten temat można przeczytać w tym poście.

rich-intellisense-on-jquery-ajax-function

 

3. Bower i npm Package Restore Settings

Visual Studio 2015 rozpoczął wspieranie Bower’a i npm’a. Integracja z tymi dwoma package manager’ami była świetna, ale była też jedna bolączka – modyfikacja czegokolwiek w w pliku package.json i zapisanie zmian, zawsze wywoływało polecenie npm install. To samo dotyczyło się bower’a. Taki stan rzeczy niósł za sobą pewne konsekwencje, pomyślmy ile czasu traciliśmy na oczekiwanie aż ten proces się skończy, ileż mieliśmy okazji na wypicie kawy i przeglądanie Facebook’a. VS 2017 przychodzi nam z pomocą na to marnotrawstwo czasu. Od teraz mamy kilka opcji ustawień, możemy uruchamiać przywracanie pakietów w dwóch przypadkach: podczas otwierania projektu lub przy zapisywaniu. W IDE wystarczy wejść w Tools Options > Projects and Solutions > Web Package Management > Package Restore:
przechwytywanie2222

Aby pozbyć się tego uciążliwego procesu, wystarczy oznaczyć Restore On Save na false. Oczywiście każde rozwiązanie ma swoje wady – tego jest to, że teraz deweloper po każdej modyfikacji pliku package.json musi się troszczyć o przywrócenie pakietu, jednak tutaj z pomocą może nam przyjść npm Task Runner.

4. .NET Core Migration Tooling

Nowe narzędzie o wdzięcznej nazwie .NET Core RTM tooling będzie dostępne w VS 2017 RTM, co spowoduje przejście z plików project.json i *.xproj do pliku *.csproj bazującego na nowym MSBuild. Microsoft rezygnuje z plików project.json, a szkoda, bardzo ułatwiały one pracę z pakietami, a teraz wszystkie projekty które zaczęliśmy już tworzyć w .NET Core musimy wyemigrować do nowego pliku projektowego. Z pomocą przyjdzie nam zaktualizowane .NET Core SDK które będzie zawierało polecenie dotnet migrate w CLI (od wersji 1.0.0-preview 3). Po wykonaniu takiego polecenia zostanie utworzony także folder z kopią zapasową, który będzie zawierał poprzednie wersje zmienionych plików, takich jak global.jsonproject.json*.xproj oraz plik solucji. W miejsce tych plików zostanie stworzony nowy plik *.csproj. Zostanie także stworzony log migracji w pliku UpgradeLog.htm.

Co nowego wniesie plik *.csproj? Został on „odchudzony” z tych wszystkich GUID-ów, posiada faktycznie potrzebne właściwości które programiści będą chcieli zmieniać od ręki a także zrezygnowano z długich list załączonych plików, no i jako wisienka na torcie – wszystkie zmiany będą się odbywały w czasie rzeczywistym. Więcej informacji można znaleźć tutaj. A tak wygląda przykładowy plik csproj:

przechwytywanie1111

5. Live Unit Testing

Deweloperzy którzy aktualnie używają NCrunch’a będą niedługo mogli z niego zrezygnować, gdyż nowy feature ze stajni Microsoft’u o dumnej nazwie Live Unit Testing może wywołać wiele pozytywnych emocji. Co prawda funkcjonalność nie będzie posiadała wszystkich opcji NCrunch’a, przynajmniej nie na ten moment, ale dla tych którzy nie potrzebują zautomatyzowanego testowania współbieżności, ta funkcja będzie przełomem.

Wyobraźmy sobie możliwość obserwowania obserwowania pokrycia testami wprost z edytora kodu przy lewym marginesie kodu naszej klasy – od teraz to będzie rzeczywistością. Bonusem jest to, że nawet nie będziemy musieli odpalać testów ręcznie, a będzie się to działo automatycznie, podczas pisania kodu. Tylko czy nasze komputery i środowiska to wytrzymają? Zielone fajeczki będą pojawiały się obok numeru linii automatycznie w miarę dodawania kodu w celu odzwierciedlenia bieżącego stanu wykonanego testu. TDD is back!

lut-glyphs-in-the-ide-1

Zielone ptaszki będą informowały o tym, że test wykonał się poprawnie, czerwone krzyżyki, że niestety, ale test się wysypał, niebieskie kreski – będą informowały o braku pokrycia testami danego fragmentu kodu.

Dużym minusem tej funkcjonalności jest to, że będzie dostępna tylko i wyłącznie w wersji Enterprise Visual Studio. Live Unit Testing wspierać będzie C#, Visual Basic projekty .NET Framework. .NET Standard i Core jest na roadmap’ie. xUnit i NUnit będą oba wspierane

 

Dodaj komentarz

avatar
  Subscribe  
Powiadom o