Discussion :

[Louis-Guillaume Morand]

Bonjour,

Dans le même état d'esprit que : Témoignages sur Visual Studio .NET

Nous vous demandons aujourd'hui ce que vous pensez de Visual Studio .NET 2005.

La migration de Visual Studio .NET 2003 à 2005 vous parait-elle insdispensable ou annecdotique ?

Qu'apréciez-vous dans Visual Studio 2005 ? Qu'est-ce qu'il reste encore de perfectible ? Quel sont les manques de cet IDE ?

Votre avis nous interesse, les meilleurs témoignages (pas les plus élogieux, mais les plus argumentés) seront sélectionnés et publiés sur une page consacré à Visual Studio .NET 2005.

[Thomas Lebrun]

Je teste la version "stable" (RTM) depuis quasiment le début de sa sortie et je dois admettre que c'est un vrai plaisir de travailler avec


Autant les version Beta étaient lentes et parfois buggées, autant, avec la RTM, je n'ai eu (à ma connaissance) aucuns soucis et le lancement est très rapide.

Beaucoup plus fluide, très pratique.

Toutes les nouveautés qui accompagne VS 2005 (ClickOnce, etc...) font du développement une chose de plus en plus aisée.

Bref, un vrai plaisir à utiliser

[Maniak]

Et je présume qu'on ne peut pas l'utiliser sans convertir les projets en .NET2 ? :)

(pas encore eu l'occasion d'installer la version du lancement, ce sera pour ce week-end :)

Mais s'ils ont refait le coup (foireux) de bloquer l'environnement sur une version de framework spécifique, je ne suis pas prêt de l'utiliser au taf. Le temps que tout le monde se mette à jour...

[neguib]

Eh oui Maniak l'environnement VS2005 est bien bloqué sur la Framework 2.0, la preuve en est que des projets sur Framework antérieures sont dixit "convertis"
L'effort qui est fait pour surAssister le mode design, je ne peux que le reconnaitre > la productivité doit être le but. Mais j'en deduirai difficilement que la qualité du projet ainsi developpé sera meilleur
Pour l'instant je n'emploie 2005 que sur un plan non professionnel proprement dit, mais j'apprécie de pouvoir encore créer un projet vide et d'étudier pas à pas les possibilités d'architecturage notamment en utilisant les diagrammes de classes. Je ne peux en dire plus pour l'instant, car trop recent dans l'utillisation régulière de VS2005(Beta2)

[prophetky]

Franchement pas mal, j'ai été jeudi au lancement de VS 2005 et SQL Server 2005 et franchement il a un très bon potentiel ce VS 2005

[Admin]

Pareil, le produit me semble très bien, je suis un novice en .Net, mais on se fait ses marques très très rapidement, comme l'a dit Morpheus, la simplicité de developpement associé à la simplicité de déploiement en fait une solution idéale.

[Admin]

Et je présume qu'on ne peut pas l'utiliser sans convertir les projets en .NET2 ?

Juste pour info :

# Si vous ne souhaitez pas - pour différentes raisons - avoir deux versions différentes de Visual Studio sur les postes de vos développeurs, vous pouvez configurer Visual Studio 2005 de façon à cibler le .NET Framework 1.1 au moment du build. Jomo Fisher de l'équipe MSBuild vous explique comment procéder sur son Blog.

[Thomas Lebrun]

Et je présume qu'on ne peut pas l'utiliser sans convertir les projets en .NET2 ?

Juste pour info :

# Si vous ne souhaitez pas - pour différentes raisons - avoir deux versions différentes de Visual Studio sur les postes de vos développeurs, vous pouvez configurer Visual Studio 2005 de façon à cibler le .NET Framework 1.1 au moment du build. Jomo Fisher de l'équipe MSBuild vous explique comment procéder sur son Blog.

Wep: http://blog.developpez.com/index.php?blog=9&title=compiler_une_application_avec_le_framewo_2005&more=1&c=1&tb=1&pb=1

Par contre, j'ai pas eu l'occasion de tester

[Admin]

Après quelques tests de ClickOnce, 2 choses, 1 bien et l'autre moins :
- on peut faire du ClickOnce avec un autre Webserver que IIS
- il faut que le client Web par défaut soit IE sinon le fichier .application s'ouvre dans le navigateur au lieu d'etre interprété par le framework .net

[boleduch]

Wep: http://blog.developpez.com/index.php...&c=1&tb=1&pb=1

Par contre, j'ai pas eu l'occasion de tester

Bonjour,

Est-ce que qqun parmi vous a eu l'occasion de tester cette possibilité ?

[Harry_polin]

sur le framework .Net 2.0 Y'a encore pleins de bugs déjà présents dans le framework 1.1 et qui n'ont pas été résolus.

Notamment avec le TabControl, quand tu commences à vouloir mettre les onglets à droite par exemple, le texte des onglets ne s'affichent plus.
Si tu mets un SlideContainer et que dans la partie droite tu mets un TabControl avce deux onglets et un control en Dock.Fill dans le premier onglet, quand tu vas bouger le slider, le control en Dock.Fill ne se sera pas redimenssionné.

Au niveau des controles j'en attendais plus. A part tout ce qui est Strip, le reste n'a pas beaucoup changé.

Mais y'a quand meme du mieux

[Maniak]

Bon... petite soirée passée avec VSNET2k5 (même pas le framework, juste l'IDE), sur une appli web faite en 1.1.
Le portage se fait relativement facilement, pas de problème, et ça marche très bien après. Impec.

Bien.

Maintenant je vais essayer de me retenir, parce que je risquerais de ne pas être poli.

Pour le moment, en attendant de creuser davantage, commentaires et questions en vrac :

- Resharper 2.0 est inutilisable avec des projets web qui utilisent des UserControls. Il passe en revue chaque .ascx/.aspx (bonjour la lenteur) et si le compilo ASP.NET intégré se vautre (fréquent pour peu qu'on fasse un <%=Toto.Titi %> avec Toto qui se trouve être nul à l'instant T, forcément), il se crashe en flammes. k, là ça semble être un problème de Resharper, si c'est bien lui qui fait le tour de ces fichiers. Par contre s'il fait ce tour parce que VSNET lui dit qu'il est capable de les compiler, j'ai une question :

- comment est-ce qu'on désactive le compilo ASP.NET intégré à VS.NET ? Il peut être utile parfois (parfois), mais 1) c'est pas rapide, 2) c'est loin d'être parfait (il se vautre notamment sur les templated controls avec des "Cannot switch views" divers et variés).
En mettant 'Source Code Editor' par défaut pour ces fichiers, il n'y a plus de problème pour l'édition (même réglage à faire que pour être tranquille sous VSNET2003, ça va, pas dépaysé), mais pour Resharper j'aimerais bien dégager le compilo lui-même :)

- c'est un bug bizarre chez moi, ou le menu Build n'a plus que les commandes Build pour la solution et le projet en cours, mais tout le reste (Rebuild/Clean notamment) n'est accessible que par menu contextuel sur les projets/solution dans l'explorateur de solution ? Parce que si ce n'est pas que chez moi, qu'est-ce qu'ils ont fumé ?

- pas moyen de faire marcher de raccourcis-clavier sur View.NextTask et View.PreviousTask
Ça marche pour plein d'autres (encore heureux), mais ces deux-là, pas moyen. Et pourtant elles sont parmi les plus utiles. Autant dire que c'est lourd. Donc même question : est-ce que c'est un bug bizarre chez moi ou est-ce que d'autres y ont droit aussi ?

- quand je vois ce genre de choses, j'ai peur. Heureusement, ça ne le fait apparemment que dans les projets Web, et je ne faisais plus de projets Web avec VSNET2003 (entre les lenteurs et le bug qui les rend incompatibles avec Subversion). Visiblement, il faudra faire pareil avec VSNET2005. Pas plus mal, ce que j'ai vu du système de compilation pour ASP.NET ne me donne vraiment pas envie d'essayer. En Class Library ça marche très bien, le déploiement, pas besoin de béquille merci, et au moins comme ça sous VSNET c'est plus rapide, plus léger, et ça n'utilise qu'un seul système de compilation. Qui marche. Bien. Lui.

Voilà pour les remarques que j'ai à faire sur VSNET2005 pour le moment. Il y en aura d'autres, j'espère positives, ce serait bien. Histoire de donner un minimum envie d'y passer. Pour l'instant, les templates sont toujours ma motivation n°1, mais ça commence à sembler léger.

Autant il y a de bonnes chances pour que le framework 2.0 soit sympa, autant VSNET2k5 pour le moment... euh... plutôt que chercher à compiler en 1.1 sous 2005, je préfèrerais chercher à compiler en 2.0 sous 2003...

(ah, qu'on pende celui qui a décidé de doubler la hauteur de la fenêtre Find&Replace. elle n'est utilisable qu'en colonne maintenant, et c'est... [zen]moins pratique[/zen])


/me inspire
affaire à suivre
/me expire

[Thomas Lebrun]

- c'est un bug bizarre chez moi, ou le menu Build n'a plus que les commandes Build pour la solution et le projet en cours, mais tout le reste (Rebuild/Clean notamment) n'est accessible que par menu contextuel sur les projets/solution dans l'explorateur de solution ? Parce que si ce n'est pas que chez moi, qu'est-ce qu'ils ont fumé ?

Aucun problème chez moi dans le Menu Build

[Maniak]

Aucun problème chez moi dans le Menu Build :roll:

Version du lancement ou autre ?

[Thomas Lebrun]

Aucun problème chez moi dans le Menu Build

Version du lancement ou autre ?

Version donnée aux abonnés MSDN, avant le lancement...

[Maniak]

Ben c'est bizarre alors.
Moi (version RTM standard filée au lancement donc) c'est clair et net, quel que soit le type de projet, le menu général Build ne contient que Build Solution / Build Project et Publish (pour Win/Web)

Rebuild/Clean, c'est uniquement via menu contextuel. Et c'est très con. Alt-B-R, c'est pratique :)

Addendum :
Bon ça s'améliore. On peut modifier les menus comme on veut, donc j'ai remis les commandes Rebuild où il faut, et la dernière build de Resharper ne se plante plus avec le compilo ASP.NET (enfin encore un peu, mais juste 2 fenêtres au chargement du projet, et pas 10 par fichier).

Par contre, on applaudit bien fort le compilo ASP.NET intégré à VS.NET, qui est tellement bien intégré qu'il indique des erreurs si on ne met pas l'attribut Language dans les directives <%@ Page et <%@ Control.
C'est pas qu'il y a un élément dans le web.config prévu exprès pour *justement* ne pas avoir à le mettre partout, mais un peu quand même.

Enfin au moins ça devient utilisable. Un de ces jours ça ne deviendra plus qu'un VS.NET 2003 avec de nouvelles icônes et un peu plus personnalisable. C'est tout ce qu'il faut :)
Mais ça aurait été bien qu'ils corrigent certains bugs de 2003 quand même.
Genre un qui me prend la tête depuis VS.NET 2002 : à un instant T, on a une partie de l'arborescence développée sur plein de niveaux dans l'explorateur de solution. On la réduit directement au niveau le plus haut (parce que bon, on ne va pas réduire chaque node à la main, ce serait un peu lourd). Plus tard, on redéveloppe ce niveau. Blam, la fenêtre de l'explorateur de solution défile 3km plus bas et il faut scroller 3km plus haut pour retrouver l'endroit qu'on vient de développer. Tout ça parce qu'il y avait des noeuds enfants déjà développés dedans. Donc en fait si, il faut fermer chaque node manuellement pour ne pas avoir ce problème...


Allez on y croit, d'ici un mois j'aurai des choses positives à dire sur VSNET 2005 :)

[greatboy]

Salut, j'ai eu l'occasion de tester VS 2005 sur un projet d'assez grande envergure, et je trouve que le faite qu'on puisse créer ses classes à partir du diagramme de classe est assez novateur pour un logiciel de developpement.
Ainsi pour les nouveaux développeur qui ont étudier l'UML il est plus pratique de passer par cette voie.

Aussi, toutes les petites nouveautés, bon ce ne sont peut etre pas grand chose de simple gadget, en font quand même un outil agréable à utilisé.

Sinon, je pense que la pluspart des entreprises qui utilisent la version 2003 vont attendre un moment, avant de passer à la version 2005. Question de stabilité de longue durée.

[Maniak]

Ainsi pour les nouveaux développeur qui ont étudier l'UML il est plus pratique de passer par cette voie.

Vi. Maintenant si la plupart des projets étaient faisables à partir de diagrammes UML, ça se saurait :)

Sinon, je pense que la pluspart des entreprises qui utilisent la version 2003 vont attendre un moment, avant de passer à la version 2005. Question de stabilité de longue durée. :D

Attendre à cause de VS2k5 oui, parce qu'en tant qu'environnement, il n'apporte quand même pas grand chose (oui oui, refactoring/tests unitaires, oui oui, resharper/nunit hein, y a pas trop photo :)

Par contre c'est surtout le framework 2.0 qui peut convaincre. Parce que lui apporte des nouveautés utiles pour les projets :)

Et vu que le passage à VS2k5 est obligatoire pour ça...

[titoux_fr]

pour une migration de 2003 vers 2005 ...pour le moment...je suis plus que mitigé...

Pas mal de choses ont sautées (design, dataset,problème de culture info)...faut revoir et retester tout l'application...

Donc moyen moyen...je changerais surement d'avis quand tout sera stabilisé...mais pour le moment...

[Maniak]

Bien, on y retourne avec un poil plus de recul :)
(encore un roman, désolé :)

Donc, VS2005. Version Standard filée au lancement (faudra qu'on me dise l'intérêt de payer super cher pour les versions 'au-dessus', parce que là tout de suite, je ne vois vraiment pas l'intérêt)


Bons points :

- avoir viré le .NET du nom. Plus rapide d'écrire VS2k5 que VSNET2k3 :)

- les tooltips 'intelligents' en mode debug. Pas super utile, mais marrant :)

- compilations en parallèle quand on est en multiproc

- moyen 'détourné' de compiler en 1.1 pour ne pas avoir à jongler entre deux VS

- pas eu de problème particulier pour la migration de projets 1.1 en 2.0. Mais bon. Projets ASP.NET en Class Library et sans designer, ça aide peut-être :)

- essentiellement pareil que VSNET2k3 pour tout le reste (sisi, c'est un bon point, comparé au reste :)

- .NET 2.0. VS2k5 n'y est pour rien donc c'est pas vraiment un bon point pour l'IDE, mais autant le mettre quelque part :)

--- les templates, enfin. Les collections typées avec Find/ForEach & co à disposition, slurp.

--- les méthodes anonymes, à condition de ne pas en abuser, slurp aussi. Carrément plus léger que toute la plomberie à sortir avant avec les delegates. Rien que ça et les templates, ça suffit à justifier de passer en 2.0.


Le reste :

- refactoring, merci mais poubelle. Je reste avec ReSharper.

- tests unitaires, merci mais poubelle. Je reste avec NUnit (et ReSharper qui est bien pratique pour lancer un test particulier au débuggueur, même si c'est lent et pas pratique pour le reste :)

- options de formatage du code, merci mais poubelle. Je reste avec Visual Assist, qui est d'autre part toujours *bien* supérieur à IntelliSense (ainsi qu'à ReSharper :)

Cela dit, pour ceux qui ne veulent pas se payer les vraies bonnes extensions mal repompées par MS pour 2k5, c'est toujours mieux que rien. Mais pas comparable.

- serveur web intégré, merci mais poubelle. Je reste avec IIS (qu'on m'explique ce qu'un dév d'applis web ferait sur une machine sans IIS ?)

- projets ASP.NET, clairement pas merci, et clairement bien au fond de la poubelle. C'était déjà bien lent et lourd avec VSNET2k3, mais là c'est vraiment ridicule.

--- pas de fichier de projet, c'est directement le répertoire qui sert. Super pour les inclusions/exclusions de fichiers, l'affichage du 'nom de projet' dans l'explorateur de solution est trop génial et l'intégration avec contrôle de code source + nant + déploiement, super, c'est gentil de faciliter les choses.

--- plus de répertoire bin, des bidouilles spéciales pour les dll référencées, des modes de compilation dont j'aimerais bien qu'on m'explique l'utilité, et le déploiement par compil + bête copier/coller sur le serveur de destination, c'était trop simple ?

--- heureusement on peut toujours faire un projet Class Library pour l'appli web et tout faire dedans. On retrouve le répertoire bin, le fonctionnement des aspx/ascx compilés à la première exécution et modifiables après coup sans avoir à recompiler toute l'appli, le déploiement par bête copier/coller, la facilité d'intégration avec nant, pas de comportement particulier du compilo, pas d'accès particulier aux fichiers, bref des projets comme les autres. C'est tellement plus simple.


Une question au passage :
Sous 2k3, quand on compile un projet, la DLL compilée est recopiée dans tous les projets de la solution qui ont une référence dessus. Très pratique, notamment pour NUnit.
Sous 2k5, il faut obligatoirement compiler tous les projets pour qu'ils soient à jour. Pas vu d'option pour changer ça. Quelqu'un a une idée ? Parce que c'est un poil lourd ça encore :)


WinForms, pas essayé et pas suffisamment pratiqué en 1.1 pour pouvoir faire de comparaison.

WebForms, je passe aussi. Je crois que je ne serai décidément jamais sur la même longueur d'onde que MS pour le web. Cela dit, les options de validation XHTML, c'est toujours bon à prendre.
C'est juste dommage pour ceux qui faisaient des applis à grands coups de designer sous 2k3 et qui se retrouvent à devoir soit tout refaire pour valider en XHTML, soit passer en 'standard'... euh... IE6 il s'appelle je crois ? :)
J'avais vu un post sur le newsgroup ASP.NET de MS dans lequel l'auteur se plaignait d'avoir beaucoup de boulot à faire pour pouvoir profiter de la validation XHTML de VS2k5, boulot causé par la nullité du code HTML généré par VSNET2k3. Marrant. C'est très vrai, on peut critiquer MS pour ça. Mais on peut aussi critiquer les dévs eux-mêmes qui ont fait des applis web sans se préoccuper du web. L'environnement ne faisait rien pour aider, c'est pas une excuse pour autant.


Compte-rendu de la situation à l'instant T dans mon cas :
Finalement content de VS2005. Plus besoin de se battre avec, on peut bosser correctement, ça ne met pas de bâton dans les roues.
Et le framework 2.0 est top.

C'est juste dommage de devoir d'abord désactiver à peu près toutes les super nouvelles fonctionnalités de l'IDE et bannir l'utilisation des projets ASP.NET proprement dits.

En fin de compte, le meilleur point de VS2005, c'est qu'il permet d'utiliser le framework 2.0. Tout (tout) l'intérêt d'y passer est là-dedans.
Mis à part ça, les nouveautés sont soit inutiles (des plugins font pareil en bien mieux depuis bien plus longtemps) soit à jeter (les projets ASP.NET... brrr... j'en ai encore des frissons rien qu'à y repenser).


Et sinon, grands remerciements à :
- ReSharper 2.0
- Visual Assist X
- NUnit
- NAnt
- TortoiseSVN et AnkhSVN