Visual Studio Upgrade Advice 2008/2010 [fermé]

Question

Nous réfléchissons actuellement à l'argumentation en faveur de la migration de vs 2005 (winforms) à vs 2008 (wpf). Mon point principal étant les nouvelles caractéristiques de conception de l'interface utilisateur.

Je crains un peu que nous consacrions beaucoup de travail à la mise à niveau de toutes les installations, mais seulement de nous obliger à faire de même lorsque 2010 arrivera? Cela conduit donc également à envisager de sauter 2008 et de simplement adopter 2010 dès sa publication.

Quelqu'un a-t-il été dans la même situation?

Aussi, tous les arguments pour et contre pour les bienvenus.

A bientôt.

Answer 1

Personnellement, j'estime qu'il serait relativement prudent de passer à 2008, car 2010 n'est que des extensions et des améliorations pour la prise en charge du temps de conception de Visual Studio pour WPF. Par conséquent, la transition ne devrait pas être si compliquée. Cela ressemble davantage à une mise à niveau 2005-2008 d’un projet Win Forms ou ASP.NET, qui est une piste de jeu.

Je trouve qu'il est préférable de mettre à niveau le plus tôt possible, afin de ne pas "s'embourber". avec le cadre / système existant. Si vous continuez à construire sur quelque chose que vous allez éventuellement remplacer, il sera de plus en plus difficile de justifier le déménagement de la direction.

Answer 2

J'étais dans la même situation et j'ai choisi de suivre la voie de l'abonnement MSDN, où je reçois tous les nouveaux outils de développement au fur et à mesure de leur sortie. J'ai une machine de rechange que j'utilise pour «la prochaine version» du compilateur, que j'utilise pour les tests de migration, donc je sais au moins à quoi m'attendre lorsque la décision doit être prise. Cela fonctionne bien pour moi, et je suppose que si vous avez une configuration de virtualisation décente, tant mieux.

Les nouvelles versions du compilateur n'ont pas cassé ma construction, mais ont gêné bon nombre de mes tests automatisés et outils de productivité complémentaires. Fondamentalement. vous avez besoin de tests de régression pour déterminer les dommages susceptibles de provoquer une nouvelle version.

Answer 3

Votre question n’a pas vraiment de sens. Voulez-vous demander si vous devez migrer des applications existantes de Winforms vers WPF? Ou voulez-vous simplement commencer à créer de nouvelles applications WPF tout en travaillant avec les projets Winform existants?

Quoi qu'il en soit, la migration de Visual Studio 2005 à 2008 est extrêmement simple. Les projets Winform existants demandent une conversion qui prend quelques secondes et qui n’a jamais échoué (dizaines de solutions et des centaines de projets convertis au cours des deux derniers mois).

Cependant, cela n'a rien à voir avec Winforms et WPF.

Si vous souhaitez commencer à créer des applications WPF, vous ne devez pas attendre VS 2010. VS 2008 offre une excellente prise en charge des deux types d'applications.

Answer 4

Je suis d'accord avec ceux qui suggèrent d'adopter VS 2008 maintenant. Une chose à considérer cependant est que WPF a une courbe d’apprentissage assez longue. J'ai eu une exposition limitée à WPF et Silverlight et je trouve que c'est un "changement de mentalité" complet. à partir du modèle WinForms. Bonne chance.

Answer 5

Je ferais le saut maintenant si j'étais à votre place. Cela minimisera l'impact du saut de 2010 en vous familiarisant avec les nombreuses nouvelles fonctionnalités auxquelles vous devez déjà vous habituer. De plus, vous bénéficierez de plusieurs mois de performances et de fonctionnalités améliorées avant que 2010 ne soit disponible.

Answer 6

Winforms vs WPF est un monde de différence. C’est un changement bien plus important que de penser à migrer de 2005 à 2008. Je n’aurais pas cela pour motiver la mise à niveau vers 2008. Je n’ai également aucune idée de l’ampleur de votre projet et si WPF est vraiment la meilleure voie à suivre pour produit. Ou bien, si le mélange d'expression est tout l'outillage dont vous avez besoin pour obtenir ces UI.

Au lieu de présenter le ton WPF, je me concentrerais sur les avantages réels que vous pouvez obtenir immédiatement. Avec 2008, vous disposez d'un multi-ciblage pour vous permettre de créer toutes les applications que vous avez créées en 2005 et de les cibler sur le framework 2.0. D'après mon expérience, 2008 est plus rapide et les améliorations apportées à la refactorisation constituent un excellent ajout. Il y a une tonne d'autres nouvelles améliorations en 2008 que vous obtenez immédiatement et que vous pouvez commencer à utiliser dès le premier jour.

Selon l’architecte en chef de 2010 de Rico, vous obtiendrez encore plus un multi- ciblage plus riche avec 2010, ce qui vous permettra d’adopter 2010 plus tôt et de ne pas vous obliger à utiliser CLR version 4 dès le départ.

Answer 7

Pour le moment, j’ai pour habitude de passer à la dernière version le plus rapidement possible. Bien que, pour un développeur d’applications, il ait ses propres pièges, Ex. .Net Framework 3.5 n’est pas disponible sur la plupart des ordinateurs, et si j’expédie le programme d’installation bootstrap de 20 Mo, il exige une connexion Internet active pour télécharger les fichiers nécessaires. Le programme d’installation complet a une capacité de 198 Mo et, même si je ne l’aime pas, je l’ai accompagné avec le logiciel.

Pour un développeur Web, même si le problème est plus facile à résoudre, il vous suffit de vous soucier de le faire fonctionner sur le serveur et les choses fonctionnent automatiquement pour les utilisateurs. Donc, si vous créez une solution Web, je pense que la migration est plus facile.

Si vous créez un logiciel d’application, je pense que vous devriez peser les avantages de la migration avec les modifications qu’il apportera à votre schéma de déploiement. Je ne sais pas combien de personnes seront d'accord avec cela, mais je crois que les développeurs d'applications devraient avoir une mise à niveau derrière.

Answer 8

Il y a une question de processus sous-jacente ici qui, à mon avis, ne devrait pas être négligée:

Quand est-il temps de mettre à niveau les outils de développement et les environnements de production?

D'une part, vous pouvez ignorer 2008, même si cela soulève la question de savoir quand l'année 2010 sera adoptée: lors de la première publication, du premier Service Pack ou d'une autre étape. Cela peut conduire à créer davantage de code hérité si vous restez bloqué sur 2005 à l'aide du cadre 2.0 et que d'autres passent à d'autres cadres. Même si vous passez à 2008, il peut toujours cibler le framework 2.0 afin que cette mise à niveau du framework .Net puisse être effectuée séparément, ce que certains aimeraient peut-être. Un autre point clé dans ce camp est de savoir qui fait la recherche pour évaluer les différences entre les versions afin de déterminer laquelle vaut la peine d'être modifiée.

D'autre part, vous pourriez suggérer une stratégie continue de préparation à la mise à niveau tous les trois ans environ, les versions de Visual Studio de la dernière décennie datant d'environ 2002, 2003, 2005 et 2008. Cela me semble être la meilleure approche car il y a plus d'évolution constante en cours plutôt que de rester bloqué du tout. Dans ce cas, il se peut que de nouvelles fonctionnalités soient utilisées, car les nouveaux outils arrivent rapidement par rapport au premier cas, où le changement peut être considéré comme un grand pas, alors que dans ce cas, il n’est pas si grand que ce soit parce que vous cherchez toujours à vous installer. 2-3 ans.

Bien sûr, alors que je dis cela, mon ancienne machine de travail utilise Visual Studio 2003, 2005 et 2008, je suis donc un peu dans ce dernier camp, ce qui est logique pour moi. Je me souviens il y a 10 ans, ma machine de travail disposait de NT 4.0, d'un processeur Pentium II 333 MHz, de 64 Mo de RAM et d'un disque dur de 4 Go qui devait comporter 2 partitions, car il ne laisserait pas une partition aussi grosse. Maintenant, ma machine de travail dispose de 4 Go de RAM, d’un processeur double cœur de 2,66 GHz et d’un disque dur de 160 Go. Pourrais-je avoir une machine avec des centaines de Go de RAM dans 10 ans? Bien que cela puisse paraître ridicule, si je partageais une machine avec une poignée de développeurs, il serait peut-être logique de répartir une énorme quantité de mémoire entre nous tous.