Visual Studio 2012 peut-il être installé côte à côte avec Visual Studio 2010?

103

Visual Studio 2012 interférera-t-il / interrompra-t-il .NET 4 et / ou Visual Studio 2010 s'il est installé côte à côte sur la même instance de Windows?

.net visual-studio-2010 visual-studio visual-studio-2012 .net-4.5 Chris Pietschmann
la source
1
oui, les deux fonctionnent, même en même temps. J'ai essayé.
Eric Yin
3
Visual Studio peut être installé côte à côte, mais sachez que VS 2012 est fourni avec .NET 4.5, qui écrase .NET 4.0. Pas de problème, sauf si vous devez encore développer pour des machines .NET 4.0.
Vaccano
4
Vous pouvez toujours développer pour les machines .NET 4.0. Vous devez juste savoir que, lorsque vous testez votre application .NET 4.0 sur votre machine VS2012, vous testerez une version de .NET différente de celle d'un client qui n'a jamais installé .NET 4.5. Alors testez sur une machine comme celle que votre client utilisera, et tout ira bien.
John Saunders
ahhhh le luxe d'un client qui fournit un environnement de test utile! Bonne chance avec ça: P
JumpingJezza
11
c'est une erreur de penser que .NET 4.5 est entièrement compatible avec .NET 4.0, ce n'est pas le cas, et en fait dans notre cas, il a cassé quelques-unes de nos solutions.
Stefan Z Camilleri

Réponses:

32

Comme Reigo l'a dit, oui. Voici le lien vers la page officielle de Microsoft avec les informations fournies par Reigo, et plus de détails: http://msdn.microsoft.com/en-us/library/ms246609%28v=VS.110%29.aspx

Niklas Söderberg
la source
36
Il "peut" être installé à côté, ce qui signifie que le programme d'installation s'exécutera avec succès. Cependant, vous ne devez pas le faire à moins que vous ne souhaitiez passer deux jours à désinstaller Visual Studio, .NET 4.5, à réparer votre framework .NET 4.0 (qui est directement modifié par l'installation bêta 4.5) et à désinstaller la pléthore d'outils SQL Server 2012 un par un. Tout cela après que votre code 4.0 précédemment fonctionnel commence à bombarder avec une erreur "Object Reference" sur une ligne qui ne contient qu'un commentaire.
mclark1129
8
Ceci est très très dangereux si vous prévoyez de continuer à développer pour .net 4.0. En effet, votre machine de développement utilisera les binaires .net 4.5 (car .net 4.5 est une mise à niveau sur place). Ces binaires ont des correctifs de bogues qui seront "cachés" lors du débogage du ciblage .net 4.0. Mais lorsque vous déployez sur une machine exécutant uniquement .net 4.0 (c'est-à-dire Windows XP), ces bogues ne sont pas corrigés pour votre utilisateur . Voir cet article pour plus de détails: social.msdn.microsoft.com/Forums/en-US/wpf/thread/…
Vaccano le
2
Essayez-le dans une machine virtuelle. Je peux confirmer les problèmes décrits par Mike C. J'ai supposé que VS2012 serait sûr d'essayer. J'ai rencontré tellement de problèmes ennuyeux que j'ai fini par ne pas faire confiance à ma machine et j'ai réinstallé Windows.
kenchilada
2
Ces problèmes existent-ils toujours avec VS 2012 RTM?
Tim Friesen
1
@TimFriesen - Le problème que j'ai décrit est toujours dans le RTM. Il s'agit d'un défaut de conception avec le plan de mise à niveau «sur place» que Microsoft a adopté pour .NET 4.5.
Vaccano
30

La version .net 4.5 est une mise à niveau sur place.

Cela signifie que les binaires pour .net 4.0 seront REMPLACÉS par les binaires pour .net 4.5 .

Microsoft a tenté d'atténuer les problèmes que cela provoque en créant une fonctionnalité «Target .net 4.0». Mais c'est très différent du ciblage des versions précédentes de .net (qui sont côte à côte depuis .net 2.0).

Comme il s'agit d'une mise à niveau sur place, "Target .net 4.0" ne peut pas vraiment la cibler. Le mieux qu'ils puissent faire est d'essayer de supprimer manuellement certaines «fonctionnalités». Ils l'ont fait (Scott Hanselman avait un article de blog sur ce sujet).

Mais ne vous laissez pas tromper en pensant que vous utilisez vraiment .net 4.0. Tous les bogues corrigés par .net 4.5 seront corrigés sur votre machine de développement et non pour vos utilisateurs .net 4.0.

Donc, si vous développez une application «ciblant .net 4.0» et que .net 4.5 est installé, vous courez un risque. Si vous utilisez accidentellement un bogue corrigé, il ne se cassera pas pour vous pendant le débogage.

Lorsque vous déployez votre application sur une machine exécutant uniquement .net 4.0 (c'est-à-dire Windows XP), ces bogues ne sont pas corrigés pour votre utilisateur .

À toutes fins utiles, ces bogues corrigés sont désormais des «bogues cachés» (pour les développeurs qui doivent encore cibler .net 4.0.

La meilleure partie est que peu importe si vous utilisez VS 2010 ou VS 2012. Une fois .net 4.5 installé, les bogues sont masqués.

Voir cet article pour plus de détails: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/c05a8c02-de67-47a9-b4ed-fd8b622a7e4a/

Vaccano
la source
Désolé, mais cela cache le point du problème. Le problème n'existe que si vous dépendez de vos tests sur votre machine de développement pour vous dire quand votre application fonctionne. Si vous pouvez tester dans l'environnement que vos clients utiliseront (et je pense que la plupart des développeurs sont dans cette position), alors vous n'avez pas ce problème. Si vous avez une deuxième machine à tester, y compris une machine virtuelle, ce n'est pas un problème.
John Saunders
4
@JohnSaunders - Nous avons tout un département QA qui teste sur notre plateforme cible. Mais de nombreuses études ont montré que les différents types de tests détectent différents types de bogues. Les éléments que je recherche lors du débogage ne correspondent pas au même niveau de bogues que mon équipe d'assurance qualité va trouver. Encore une fois, mes tests automatisés ne remarqueront pas toutes les choses que je remarquerai lors du débogage. Et enfin, écrire une fonctionnalité qui dépend d'un bug que vous ne pouvez pas corriger coûte $$$. Lorsque le bogue est détecté, plus il est éloigné de ma machine de développement, plus cela coûte cher. (Surtout si j'ai "terminé" le long métrage.)
Vaccano
"Le problème n'existe que si vous dépendez de vos tests sur votre machine de développement pour vous dire quand votre application fonctionne" - Est-ce que vous sous-entendez que vous ne testez pas votre code sur votre machine de développement? -- Ça c'est un vrai problème. Surtout pour ceux qui ne le savent pas. (Et puisque Microsoft ne l'annoncera pas publiquement, c'est beaucoup de développeurs.)
Vaccano
Les tests que j'effectue sur ma machine de développement ne déterminent pas si mon code fonctionne ou non. Ils déterminent uniquement la probabilité que le service QA trouve mes bogues dans les cinq premières minutes ou non. Je teste sur ma propre machine afin de réduire la gêne. Ce sont les tests unitaires automatisés dans les builds et les vrais tests par QA qui déterminent si mon code est livré ou non aux clients. Ces tests comprendront des tests dans un environnement comme celui des clients. Dans ce cas, cela inclurait Windows XP et .NET 4.0.
John Saunders
Je suis désolé, mais si vous avez un département QA, je ne vois pas du tout votre problème. Je ne peux pas imaginer qu'il y ait tant de bogues .NET 4.0 corrigés par .NET 4.5 que cela vous coûterait beaucoup d'argent si vous deviez écrire du code dépendant de ces bogues. Si vous pensez avoir ce problème, testez tôt et souvent sur Windows XP et .NET 4.0. Ce sont ces développeurs qui ne verront jamais les bogues qui courent le plus de risques.
John Saunders
10

J'ai été gravement brûlé par VS betas, je n'ai jamais eu de problème pour les désinstaller. Microsoft fabrique de bons logiciels, mais le programme d'installation semble toujours être la toute dernière chose à prendre en compte. Les problèmes que j'ai vus sont la désinstallation qui ne supprime pas les composants, ce qui fait bousiller l'édition commerciale et le programme d'installation ne compte pas sur les autres produits Microsoft installés et détruit leur configuration.

Celui - ci est loin avant une version bêta, ne pas l' installer sur une machine dont vous avez besoin pour faire votre travail. Ce qui empêche à peu près l'installation de VS2008. VM va bien, bien sûr.

Hans Passant
la source
2
Je viens de publier quelque chose dans les forums [ social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/ ... car il semble que l'installation remplace les assemblys .NET Framework 4.0 (je pensais que je devais être fou mais ouvrir System.Core dans Reflector a révélé que System.Runtime.CompilerServices.ExtensionAttribute était manquant). Bref faites attention là
Damian
@Damian: C'est le problème car il était avec 3.0 et 3.5: les deux étaient essentiellement des fonctionnalités supplémentaires basées sur le runtime 2.0, mais les deux étaient accompagnés d'un service pack 2.0 (qui pouvait être téléchargé séparément pour les installations 2.0 uniquement) qui a en effet changé certaines choses sous le capot. En regardant la version 4.0, c'est encore pire: Microsoft vient de livrer silencieusement de nouvelles versions via Windows Update - la version originale 4.0.30319.1 a été remplacée par .225, .235 et .237 - chacune corrigeant et introduisant des bogues ou au moins un comportement différent dans domaines spécifiques.
springy76
7

J'ai installé le RC hier et j'ai trouvé ce qui suit:

Cela provoque le gel de VS2010 lors de l'exécution de tests unitaires (cela peut être contourné en utilisant 2012 ou mstest sur la ligne de commande pour exécuter vos tests unitaires)

Cela empêche VS2010 de compiler les projets C ++, échouant avec une erreur de lien . Même après la désinstallation de VS2012 RC, ce problème persiste ... je vous déconseille donc fortement de l'installer maintenant

Orion Edwards
la source
1
J'ai eu le même problème avec l'exécution de tests unitaires dans VS 2010 après avoir installé VS 2012 RC. Pour résoudre ce problème, supprimez testimpactdata.sdf de la racine de votre solution et activez Test Impact dans vos paramètres de test.
Sergey Sirotkin
2
J'ai rencontré le problème de test que vous décrivez également. La solution que j'ai trouvée était de mettre à niveau vers Visual Studio 2010 Service Pack 1. Apparemment, c'est un problème en 2010, pas en 2012, mais il est simplement déclenché par l'installation de la version 2012 candidate. Vous devriez pouvoir installer le Service Pack même après l'installation de VS 2012 et résoudre le problème. Je ne fais pas grand-chose avec C ++ ces jours-ci, donc je ne peux pas commenter si cela est également corrigé. VS 2010 SP1 peut être trouvé ici: microsoft.com/en-us/download/details.aspx?id=23691
rbwhitaker
6

Donc, en lisant toutes les réponses, cela revient à ceci:

  • Après l'installation de VS2012, .NET 4.5 écrasera .NET 4.0.
  • Vous pouvez toujours utiliser VS2010, mais il compilera avec .NET 4.5 (puisque .NET 4.0 est remplacé).
  • Danger: vous ne pouvez plus déployer vos projets en toute sécurité sur des machines exécutant .NET 4.0.
Jenny O'Reilly
la source
5

Oui, vous pouvez, mais il est toujours recommandé d'installer d'abord les versions antérieures. Et si vous souhaitez ouvrir le projet Visual Studio 2010 dans VS 11, puis à nouveau ultérieurement, assurez-vous de ne pas utiliser les nouvelles fonctionnalités de Visual Studio 11

Reigo Hein
la source
2

Il peut être installé côte à côte mais ce n'est même pas une version bêta ..! Ne vous attendez pas à ce que cela fonctionne réellement!

Voyez ce problème que nous rencontrons, et celui mentionné par Damian dans un autre commentaire.

Oreilles de chien
la source
2

Je l'ai fait hier et je l'ai désinstallé aujourd'hui ...

Apparemment, quelque chose s'est mal passé parce que certaines applications que j'ai construites avant ont commencé à donner d'étranges erreurs concernant "Impossible de charger le module bla bla bla ...", j'ai donc tout désinstallé, forcé la réinstallation de .NET Framework 4.0 et maintenant tout fonctionne à nouveau bien!

Pedro Lamas
la source
2

Cela peut certainement causer des problèmes. Par exemple:

Dans .NET 4.0, chaque fois que l'on essaie d'enregistrer une valeur d'énumération dans LINQ-2-Entities, jup, vous l'avez deviné: ERREUR quand vous avez 4.0 GRAND SUCCÈS lorsque vous travaillez sur une machine avec 4.5 installé (oui même si l'assembly cible le client 4.0 profil!)

Faites donc attention lorsque vous utilisez cette bonne nouvelle fonctionnalité qui n'a aucune compatibilité inverse.

RVCL
la source
2

Cela fonctionne bien sur une machine 32 bits installant côte à côte, mais parfois, vous pouvez obtenir une erreur, mais la réinstallation ou la désinstallation de l'installation précédente peut être installée. Je l'ai fait au milieu du projet et cela n'affecte pas non plus les travaux précédents.

chandrabhan gurjar
la source
0

Comme cela a été dit, officiellement, vous pouvez, mais cela peut causer des problèmes.

Si vous souhaitez exécuter Visual Studio 2012, je pense que le moyen le plus sûr est d'utiliser le WMWare VMplayer gratuit et d'installer Windows 8 dessus, puis d'installer Visual Studio 2012 là-bas. Vous avez besoin d'au moins 4 Go de RAM, mais fonctionne mieux avec 8 Go ou plus. C'est ce que je fais de toute façon.

Adam Mendoza
la source
Pouvez-vous être plus précis sur les problèmes dont vous parlez?
John Saunders
0

Mon principal problème est que l'on ne peut plus exécuter de tests unitaires à partir de VS2010 après l'installation de VS2012 RTM! Il est suspendu pour toujours. Je ne peux même pas l'arrêter.

Donc pour l'instant je dirais, MS l'a encore fait, côte à côte ne fonctionne pas.

Je pense que cela peut être dû au fait qu'il s'agit d'une installation VS2010 sans SP1 appliqué.

nietras
la source
Pouvez-vous être précis sur les «tests de VS2010» auxquels vous faites référence?
John Saunders
J'ai aussi ce problème - essayer de regarder les résultats de sortie de test dans un blocage reproductible à la fois dans vs2010 et vs2013 (tous les derniers correctifs / mises à jour). j'attends mieux de vous Microsoft.
fusi
0

La bonne nouvelle est que l'installation constitue un point de restauration du système. La sauvegarde du disque dur externe est la solution à ce problème jusqu'à ce qu'une version réelle sorte ou que vous démarriez un projet à partir de zéro.

MvcCmsJon
la source
0

J'ai remarqué que les solutions Web & Loadtesting semblent défectueuses après l'installation de VS2012. Ont pris des copies et mis à niveau vers 2012 et ils fonctionnent bien. C'est juste que VS2010 ne peut plus lancer de test.

Big Ian
la source
-1

Oui, vous pouvez également facilement ouvrir un projet de 2012 à 2010 sans problème. tant qu'il utilise toujours .net 4.0.

JGilmartin
la source