Visual Studio 2017 est disponible en version finale, les principales nouveautés

Visual Studio 2017 est disponible en version finale, les principales nouveautés

Une version spéciale 20 ans

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

07/03/2017 5 minutes
49

Visual Studio 2017 est disponible en version finale, les principales nouveautés

Visual Studio 2017 est désormais disponible au téléchargement ou à l’achat, selon l’édition retenue. Pour Microsoft, il s’agit clairement de la version de la « maturité », l’éditeur ayant de grandes ambitions pour son EDI, censé répondre à tous les besoins.

Avec la sortie de cette quinzième version, Microsoft fête les 20 ans de son environnement de développement intégré. Le produit est très différent des premières versions, tant par les langages supportés que par les fonctions proposées. À ses débuts, Visual Studio étant en effet une collection d’outils spécifiques et dépendants des langages, alors qu’il est maintenant un environnement intégré, donc proposant un socle commun de possibilités pour l’ensemble des projets.

Comme nous l’a expliqué Samuel Metias, responsable Agile & DevOps chez Microsoft France, la nouvelle mouture s’articule autour de quatre grands axes : cloud, mobilité, performances et devops, ce dernier terme désignant la possibilité de rassembler sur un même objectif l’ensemble des intervenants sur un même projet.

De meilleures performances dans l'installeur et au lancement

L’une des principales améliorations de la version 2017 concerne les performances, via plusieurs changements importants. Samuel Metias nous explique ainsi que les développeurs ont opéré une « déconstruction » du produit, afin de les réassembler en divers modules. L’installation est donc nettement plus fine : elle prend moins de temps, moins de place, inscrit « beaucoup moins de clés de registres », la granularité permettant de ne choisir que les composants qui intéressent l’utilisateur.

Le chargement des projets se veut également nettement plus rapide, avec d’une part des améliorations sur les performances globales, et d’autre part un nombre plus restreint de fichiers. L’EDI peut d’ailleurs ouvrir des dossiers et considérer le contenu comme un fichier, même s’il n’y trouve pas les classiques données spécifiques à Visual Studio. Une fonction ajoutée pour qu'un développeur puisse reprendre dans le produit un code travaillé depuis un autre EDI.

visual studio installation 15

.NET Core, Docker et les langages supportés

Côté cloud, on reste sur l’orientation prise par Microsoft ces dernières années, désormais renforcée. Visual Studio 2017 peut donc évidemment gérer les projets sur site, ceux pleinement dans le cloud, ainsi que les projets de cloud hybride, qui mélange les ressources locales et distantes. L’EDI est en phase avec les versions 1.0 et 1.1 de .NET Core et ASP.NET Core, qui sont pour rappel des « reboots » de ces technologies, mais en open source et multiplateforme.

L’intégration de Docker est également beaucoup plus présente, ce qui n’a rien d’une surprise. En théorie, un développeur peut donc créer une application, l’empaqueter dans un conteneur Docker et l’envoyer sur Azure en quelques clics.

Pour le développement lui-même, la liste des langages supportés ne change pas. On reste donc sur C++, C#, JavaScript, Visual Basic .NET et ainsi de suite. Seul Python ne fait pas encore partie de la version finale, alors qu’il est présent dans les préversions, une question de « qualité » d’intégration selon Samuel Metias.

visual studio 2017

Test unitaires « live », IntelliSense et C++17

Plusieurs fonctionnalités apparaissent pour l’édition. Les « live unit tests » affichent par exemple au cours de la frappe les lignes de code qui peuvent faire l’objet de tests unitaires, tout en indiquant si ces tests réussissent ou échouent. « Run to click » permet de son côté d’exécuter un programme jusqu’à la ligne de code choisit puis de le mettre en pause dans le débogueur.

L’enrichissement d’IntelliSense continue aussi, avec une plus grande automatisation. Par exemple, écrire deux lettres en majuscules liste immédiatement toutes les méthodes qui les ont dans leur nom. C++ gagne de son côté un certain nombre de nouveautés héritées de la norme C++17 et supporte désormais les scripts CMake.

Xamarin plus présent, Redgate pour les bases de données et Git

Côté mobilité, l’intégration de Xamarin est également plus présente, ce dont on pouvait se douter après le rachat de l’entreprise par Microsoft. On retrouve donc IntelliSense dans le XAML des Xamarin Forms, ainsi qu’un prévisualiseur pour ces dernières. Par ailleurs, certaines étapes sont largement simplifiées. Par exemple, ajouter un service dans une application mobile importe automatiquement toutes les dépendances associées.

Pour le devops, il s’agit surtout de simplifier des étapes qui pouvaient auparavant être rébarbatives. Certains outils tiers, comme ceux de Redgate, ont donc été intégrés pour permettre notamment de chercher du code SQL sur plusieurs bases de données en même temps. L’intégration de Git est elle aussi renforcée, avec un changement important au passage : Visual Studio n’utilise plus la bibliothèque libgit2 de GitHub mais directement l’exécutable Git.

visual studio 2017

Les mêmes éditions, aux mêmes tarifs

Les éditions et les tarifs de cette version 2017 ne changent pas. On retrouve donc essentiellement les moutures Professionnal et Enterprise, pour respectivement 639 et 3 289 euros, bien que des variantes existent, notamment MSDN pour la Professionnal. La version Community, gratuite pour les développeurs seuls ou en petites équipes, est toujours présente elle aussi, reprenant dans les grandes lignes la mouture Pro.

Notez qu’on ne sait pas si cette version finale correspond à la dernière Release Candidate distribuée, mais il est dans tous les cas possible de passer par une mise à jour directe, sans besoin de le désinstaller puis de le réinstaller. Nous avons posé la question à Microsoft, qui devrait revenir vers nous avec la réponse.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

De meilleures performances dans l'installeur et au lancement

.NET Core, Docker et les langages supportés

Test unitaires « live », IntelliSense et C++17

Xamarin plus présent, Redgate pour les bases de données et Git

Les mêmes éditions, aux mêmes tarifs

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (49)


Rien ne remplace git en ligne de commande :p








revker a écrit :



Rien ne remplace git en ligne de commande :p





Sauf quand tu as dans l’équipe des débutant qui font un peu tout et n’importe quoi, avec une interface graphique les gens comprennent mieux leurs action.

De plus cela permet d’avoir une vue d’ensemble plus rapide qu’avec les lignes de commande, car regarde un diff avant commit en ligne de commande ^^



+1. Quand on voit la verbosité d’un IDE git…ca fait peur.


Petit retour personnel sur ASP .NET Core MVC.

Je développe sous macOS et Visual Studio Code pour dev web côté backend. (TypeScript/React/MobX pour le front).

J’aime bcp même si la plateforme n’est pas encore assez mature.

Je l’ai choisi à cause de Entity Framework qui est bien supérieur aux ORM SQL en JS existants.



Mais si un jour un ORM de la même qualité débarquait en JS, je coderais aussi le backend en TypeScript.



C# ne propose tjrs pas les types non nullable contrairement à TypeScript 2 qui devient vraiment mature désormais.



Bref, avant je faisais du Rails (et encore avant C++/Qt/GTK+) et maintenant j’approuve la politique de Microsoft de tous mettre sous license Apache sur GitHub, impensable il y a encore peu.



Bravo Microsoft !


Que du bon dans cette version, pas une révolution mais des ajouts sympathiques.


Cool. Pour une fois, je vais tester la version communautaire, on va voir si ça suffit…


Je comprends très bien le fonctionnement de Git, mais TortoiseGit (voire même SourceTree) me permettaient d’être bien plus rapide et confiant qu’en ligne de commande.

Je ne sais pas pour VS 2017, mais l’interface graphique Git dans VS 2015 était assez déplorable et là effectivement la ligne de commande pouvait être plus efficace.


Que dire a part <img data-src=" />



Ah si, vaux mieux formater le pc quand on installe un Visual Studio <img data-src=" />








Folgore a écrit :



Que dire a part <img data-src=" />



Ah si, vaux mieux formater le pc quand on installe un Visual Studio <img data-src=" />





C’est pas faux.

J’ai fait le fou jsuis passé de la RC à la community, j’ai encore tous les raccourcis pour la RC c’est un sacré bordel.

Du coup à la sortie de la creative update je formate &gt;&lt;



<img data-src=" />



Sinon, quid de la “télémétrie” forcée dans les applications développées avec Visual Studio ? Intox ?



Pour le processus d’installation, c’est que du bon. \o/


Par contre, le redémarrage en fin d’installation, ça fait un peu archaïque..


Pas de redémarrage pour moi.

Ca dépend de ce que tu as déjà d’instalé sur ta machine.



Je me souviens pour les installations automatiques de VS2015, il fallait installer .Net avant pour ne pas avoir de redémarrage forcé après installation.


Cool…! Je vais sur le site de jetBrains pour télécharger ça…. Mais, attendez….&nbsp;<img data-src=" />



(Ok c’est peut-être un peu fort pour un mardi)&nbsp;<img data-src=" />




Pour le développement lui-même, la liste des langages supportés ne change pas. On reste donc sur C++, C#, JavaScript, Visual Basic, .NET et ainsi de suite.





.NET n’est pas un langage… mais bon, cette erreur est tellement fréquente que je me demande pourquoi je prends encore la peine de la signaler :P









revker a écrit :



Rien ne remplace git en ligne de commande :p







Tout à fait d’accord. Les GUI sont presque toujours assez limitées en fonctionnalité par rapport à la CLI, et utilisent souvent des termes différents de ceux de git (genre “revert” dans TortoiseGit qui n’a pas le même sens que le “revert” de git…)







ilo34 a écrit :



Sauf quand tu as dans l’équipe des débutant qui font un peu tout et n’importe quoi, avec une interface graphique les gens comprennent mieux leurs action.





Oui et non… j’ai l’impression que l’utilisation d’une GUI a plutôt tendance à ralentir l’apprentissage, car elle évite de se poser les questions nécessaires sur le fonctionnement de git. Perso j’ai commencé à vraiment comprendre git quand je me suis mis à la ligne de commande, avant je l’utilisais à peu près de la même façon que SVN…







ilo34 a écrit :



De plus cela permet d’avoir une vue d’ensemble plus rapide qu’avec les lignes de commande, car regarde un diff avant commit en ligne de commande ^^







Pour le diff, c’est vrai. C’est quasiment le seul truc pour lequel j’utilise parfois une GUI.







Folgore a écrit :



Que dire a part <img data-src=" />



Ah si, vaux mieux formater le pc quand on installe un Visual Studio <img data-src=" />







L’installeur de VS2017 est supposé être “low impact” et s’installer de façon “isolée” sans foutre le bordel partout… Ce qui ne l’empêcher pas de demander de fermer VS2015 pendant l’installation et de redémarrer à la fin <img data-src=" />







Trollalalala a écrit :



Cool…! Je vais sur le site de jetBrains pour télécharger ça…. Mais, attendez…. <img data-src=" />



(Ok c’est peut-être un peu fort pour un mardi) <img data-src=" />







Au delà du troll, Rider est assez prometteur… Visual Studio est un des seuls trucs qui me font rester sous Windows, mais le jour où Rider sera à un niveau comparable, j’envisagerai de changer.



“Comme nous l’a expliqué Samuel Metias, responsable Agile & DevOps chez Microsoft France”&nbsp;Totalement hors sujet, mais c’est un ancien camarade de promo, qui en a fait de la route depuis :)


Pourquoi installer des GUI git supplémentaires type Turtoise/SourceTree alors que git vient de base avec une GUI ? (sobrement appelée Git GUI, accessible d’un clic droit dans l’explorateur ou sinon dans le menu démarrer ou en tapant git gui dans une ligne de commande). Elle gère 90% des actions Git courantes en 23 clics max.


Ca dépend vraiment de ce qu’on souhaite faire. J’alterne régulièrement entre Git Bash, Git GUI et Tortoise selon ce que je veux faire (l’outil de VS étant encore trop limité, je m’en passe). Mais 95% du temps, j’utilise TortoiseGit, et je ne vois absolument pas comment une CLI pourrait être plus rapide pour ces 95%, n’en déplaise aux extrémistes.


Téléchargé, testé et approuvé.

J’attendais d’énormes améliorations d’Intellisense pour le C++ comparé à VS2015 car sur du code template, il partait rapidement dans l’hyper espace, ou encore il matchait des fonctions homonymes mais pas dans le bon contexte.



Quant à l’intégration de git (déjà présente dans les versions antérieures) je la trouve plutôt réussie pour les opérations les plus courantes : commit, pull, push, merge, diff, revert, switch de branche. Le fait aussi que VS ajoute automatiquement les nouveaux fichiers permet d’une part d’éviter les push partiels foireux, d’autres part quand on configure gitignore on voit en live les conséquences.

Par contre, il ne respecte pas les settings de git du style pull rebase, ni les extensions type LFS. Sans ces petits soucis, je pourrais me passer entièrement de la ligne de commande.








ilo34 a écrit :



Sauf quand tu as dans l’équipe des débutant qui font un peu tout et n’importe quoi, avec une interface graphique les gens comprennent mieux leurs action.

De plus cela permet d’avoir une vue d’ensemble plus rapide qu’avec les lignes de commande, car regarde un diff avant commit en ligne de commande ^^





Github desktop n’est pas trop mal je trouve.



Presque pareil pour moi sauf que pas du tout ^^

&nbsp;J’ai pris Asp.NetCore car la version ASPNet est vouée à disparaitre, tout comme EF non core, et que j’aime bien le C# <img data-src=" />

Par contre il est vrai que EFCore a encore quelques lacunes, mais ASPNetCore pas trop je trouve (il y a bien deux-trois détails, mais rien d’insurmontable).



Cependant coder avec VS2015 est déjà bien sympa, j’ai essayé 2017 vers le début, au moment où il cassait tout les projets… Du coup je n’ai pas encore retenté, mais je pense que ça va venir très vite, à condition qu’il ne prenne pas “trop” de place.

&nbsp;







Arcy a écrit :



<img data-src=" />



Sinon, quid de la “télémétrie” forcée dans les applications développées avec Visual Studio ? Intox ?



Pour le processus d’installation, c’est que du bon. \o/





Je confirme, je n’ai pas encore trouvé comment le virer pour que ça ne fasse pas planter le site… Je ne me suis pas énormément penché sur l’histoire car c’est pas ma priorité, mais c’est bien relou… Surtout que tu atteins très très rapidement les quotas, après il faut payer!









tom103 a écrit :



Tout à fait d’accord. Les GUI sont presque toujours assez limitées en

fonctionnalité par rapport à la CLI, et utilisent souvent des termes

différents de ceux de git (genre “revert” dans TortoiseGit qui n’a pas

le même sens que le “revert” de git…) &nbsp;



&nbsp;

Désolé mais je ne suis pas du tout d’accord. Depuis au moins 18 mois avec TortoiseGit je ne suis pratiquement jamais obligé d’utiliser la ligne de commande, et toutes les opérations courantes se font rapidement et sans prise de tête. En fait la seule opération que je vois pour laquelle je dois encore passer par la CLI c’est merge-base, et c’est une opération dont l’utilité est plutôt rare.

Donc 99% du temps j’utilise une GUI, les 1% restants j’ouvre la CLI.

Le problème de nomenclature est anecdotique, tant qu’on arrive à travailler.



Ca se passe bien Typescript / React ? D’après ce que j’ai pu voir l’écosystème react se base plus sur ES6 que TS . Au niveau du build tu utilises quelle stack (babel / webpack, autre ? ).



A part cela je ne connaissais pas mobx, ça semble pas mal !








revker a écrit :



Rien ne remplace git en ligne de commande :p





Autant pour tout le reste je dis oui, autant pour git, ça me stresse beaucoup trop. Même si je connais assez bien, je ne peux pas m’empêcher de douter ^^



En CLI je me contente des commit/push/pull/diff/merge. Si j’ai besoin de faire un truc un peu tordus clairement je préfère une GUI (Gitkraken est assez génial pout ceux qui ne connaissent pas)



Sinon il a l’air pas mal ce nouveau VS mais c’est pas ça qui va me faire revenir sous Windows <img data-src=" />



Bon j’utilise VS code sous linux mais ce n’est pas franchement comparable.



Je trouve la ligne de commande tellement plus claire. On comprend tout de suite ce qu’il se passe. Je ne supporte pas les versions GUI ^^



Mais chacun a sa propre sensibilité ^^


Je ne connais pas du tout rider vu que je ne travaille pas ce langage, mais phpStorm et intelliJ franchement, c’est une tuerie !








Arcy a écrit :



<img data-src=" />



Sinon, quid de la “télémétrie” forcée dans les applications développées avec Visual Studio ? Intox ?&nbsp;





La dernière fois, j’ai tellement galéré pour ajouter de la télémétrie sur une application desktop que je développais… ça m’étonnerait qu’ils arrivent à l’ajouter en catimini;









revker a écrit :



Rien ne remplace git en ligne de commande :p





J’ai récemment découvert Cycligent git tool qui pour moi est la première interface graphique vraiment exploitable… Tout le monde autour de moi l’adopte.

ça réduit énormément l’intérêt de la ligne de commande…









tom103 a écrit :



.NET n’est pas un langage… mais bon, cette erreur est tellement fréquente que je me demande pourquoi je prends encore la peine de la signaler :P&nbsp;





Oui alors on se calme, parce que cette erreur, elle n’a jamais été faite sur NXI ;)



En l’occurence, c’est juste une virgule en trop après Visual Basic.









rbag a écrit :



Ca se passe bien Typescript / React ? D’après ce que j’ai pu voir l’écosystème react se base plus sur ES6 que TS.







Aucun soucis pour utiliser React avec TypeScript (et les autres libs, react-router, redux, Flux…). Effectivement la documentation et la communauté React utilise plutôt Babel mais ça n’a pas d’incidence.

À savoir que facebook le créateur de React, a créé un concurrent à TypeScript qui s’appelle Flow mais je ne recommande pas, c’est peu utilisé et les retours que j’ai pu lire (Reddit, hacker news) sont moyens.

Y’a aussi Inferno qui est réimplantation de React en plus rapide et qui est écrit en TypeScript. Le dev d’Inferno a été embauché récemment par Facebook pour travailler sur React. Je recommande pas Inferno, ya des risques d’incompatibilité avec React et les perfs de React sont de toute façon correctes et vont encore s’améliorer.







rbag a écrit :



Au niveau du build tu utilises quelle stack (babel / webpack, autre ?)







Webpack 1 (version 2 vient juste de sortir), c’est ce que tt le monde utilise désormais.







rbag a écrit :



A part cela je ne connaissais pas mobx, ça semble pas mal !







Au top ! D’ailleurs MobX est écrit en TypeScript :)









tanguy_k a écrit :



C# ne propose tjrs pas les types non nullable contrairement à TypeScript 2 qui devient vraiment mature désormais.&nbsp;





struct au lieu de class ça ne résout pas ton problème ? Les objets non nullables sont en général plutôt léger, et les struct sont justements faites pour ça…



Pour les objets plus complexes, en injection te ne construis rien directement, ou alors tu passe par une factory, c’est donc déjà built-in de renvoyer un default qui est non nul…



Pour simplement faire des forms en powershell et rajouter des boutons et du code derrière. Il faut prendre quel module parce que j’ai pas l’impression que ce soit disponible :/ ?


Salut Jb, qu’est ce qui te manque dans la community 2015, par rapport à ta version ?


Je pense qu’il voulait dire de manière générale et pas que sur Nxi, bcp de gens autours de moi assimilent .NET à un langage.








Krystanos a écrit :



struct au lieu de class ça ne résout pas ton problème ? Les objets non nullables sont en général plutôt léger, et les struct sont justements faites pour ça…



Pour les objets plus complexes, en injection te ne construis rien directement, ou alors tu passe par une factory, c’est donc déjà built-in de renvoyer un default qui est non nul…





Sinon y’a aussi le namespace Contracts, et plus précisément Contract.Requires qui permet de donner des contraintes sur les les arguments d’une fonction. Ces contraintes sont testées statiquement à la compilation et non au runtime.



Du tout bon cette version. Le nouveau format d’installation/désinstallation des nouvelles fonctionnalités est un gros plus.

D’ailleurs pour ceux qui veulent faire un bon gros nettoyage des familles: =&gt;https://github.com/Microsoft/VisualStudioUninstaller ça marche vraiment bien. Plus aucune trace.



Par contre il y a quelque chose qui m’embète, il y a effectivement d’avantage de Xamarin, avec Template de projet. Xamarin qui support Windows phone 8.1 mais ce n’est pas le cas de VS2017…

C’est dommage avec Xamarin forms ce n’est pas beaucoup plus couteux de faire une app qui tourne sur WP8…








Slippropre a écrit :



D’ailleurs pour ceux qui veulent faire un bon gros nettoyage des familles: =&gt;https://github.com/Microsoft/VisualStudioUninstaller ça marche vraiment bien. Plus aucune trace.





&nbsp; Merci je vais tester ca ce soir :oui2:



Sinon y’a un lien pour d/l une version complète ? parce que leur stub alakon …








LostSoul a écrit :



Sinon y’a un lien pour d/l une version complète ? parce que leur stub alakon …







Y en a pas mais tu peux te faire ton installeur offline :https://docs.microsoft.com/en-us/visualstudio/install/create-an-offline-installa…



edit : grillé









Strimy a écrit :



https://docs.microsoft.com/en-us/visualstudio/install/create-an-offline-installation-of-visual-studio



Peut être sur MSDN aussi





non, pas d’iso ou d’exe complet sur MSDN non plus :(



C’est pelant de pas avoir d’ISO pour ce genre de truc quand même, je trouve








Slippropre a écrit :



Par contre il y a quelque chose qui m’embète, il y a effectivement d’avantage de Xamarin, avec Template de projet. Xamarin qui support Windows phone 8.1 mais ce n’est pas le cas de VS2017…

C’est dommage avec Xamarin forms ce n’est pas beaucoup plus couteux de faire une app qui tourne sur WP8…&nbsp;





WP8 est quasi mort de toutes façons (support jusque juillet 2017), et les app WP8 devraient etre transformées en UWP pour Windows10/W10m.



Mais dans tout cette histoire, j attends tjs la généralisation du .NET Standard 2.0 qui devrait enfin garantir une base commune entre .NET Framework, .NET Core et Mono:

https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

VS2017 est un pas important dans cette direction, mais apparemment, on n y est pas encore.



J’ai installé VS2017 mais dans l’état, je ne peux m en servir car je dois d’abord attendre la MAJ des extensions que j utilise massivement (dont VSAE pour du dev avec SCSM2016)

&nbsp;



On aura ptet une ISO prochainement qui sera un compromis, car &nbsp;l install complete de VS2017 prends au dela de 40 Go, donc j imagine qu on aura pas tout sur un ISO DVD de 4.5 Go.

A l opposé, l install mini est de 600 Mo.


bah, je sais pas. justement.



J’ai jamais pris l’habitude de prendre la version community.


on peut enfin collapse les boucles et autres IF…. <img data-src=" />








ZoZo a écrit :



Je comprends très bien le fonctionnement de Git, mais TortoiseGit (voire même SourceTree) me permettaient d’être bien plus rapide et confiant qu’en ligne de commande.





De ce que j’ai lu (et qui me semble logique), TortoiseGit n’aide pas les débutants avec git à bien comprendre ses mécanismes et encourage une manière de continuer de procéder à la SVN/CVS.



Quand on connaît comment fonctionne Git,&nbsp; je ne vois pas en quoi TortoiseGit encourage à procéder à la SVN/CVS, ou même entrave la bonne utilisation de Git tel qu’il a été pensé.

Pour les débutants, c’est certainement une autre histoire. Mais je pense que la ligne de commande n’aide pas non plus franchement à comprendre d’elle-même, le débutant va rester coincer, même avec le mode d’emploi style “man” sous les yeux. Pour comprendre il faut de toute manière passer par une formation, que ce soit par un instructeur, un didacticiel ou un livre.