windows - seconde - site compagnon new password 2de




Visual Studio 2012 Une opération à distance prend plus de temps que prévu (5)

J'exécute Visual Studio 2012 sur Windows 8 64 bits. J'ai un projet 64 bits en contrôle de code source et j'essaie de l'exécuter à la maison sur mon ordinateur Windows 8. L'application se construit avec succès, mais le débogueur distant ne fonctionne pas du tout.

Il indique "Une opération à distance prend plus de temps que prévu". Je comprends pourquoi sa distance, étant que Visual Studio 32 bits doit accéder à msvsmon.exe pour déboguer via des applications 64 bits, mais je n’ai jamais vu cela se produire sur une machine locale où le code source a été extrait.

J'ai essayé de réinstaller Visual Studio 2012, de jouer avec les ports (4016) et de fonctionner en tant qu'administrateur. Vérifié que le VPN n'était pas un problème en désinstallant le client.

Je suis maintenant à court d'idées. J'ai essayé de créer un tout nouveau projet local à tester et à définir en 64 bits, mais l'opération n'aboutit toujours pas.

Des idées ou des suggestions? Est-ce un problème connu avec Visual Studio 2012 sur Windows 8?


Ce qui a fonctionné pour moi, c’est la désinstallation d’un programme appelé «sendori».


Je pense que vous devriez essayer ceci:

  • Exécutez cmd.exe en tant qu'administrateur.
  • Tapez et exécutez les deux lignes de commande suivantes:

netsh winsock réinitialiser le catalogue

netsh int ip reset reset.log hit

  • Cela peut indiquer qu'un redémarrage est nécessaire, mais en réalité, ce n'est pas nécessaire.
  • Essayez à nouveau de déboguer votre application, le problème devrait être résolu.

EDIT: Désolé de ne pas avoir fourni d’explication auparavant. La réponse provenait en fait d'un forum chinois et l'auteur original ne l'expliqua pas beaucoup. Mais il a dit que c’est parce que Visual Studio est un programme 32 bits qui risque d’avoir des problèmes d’accès au réseau sous Windows 7 64 bits, et la solution susmentionnée réinitialise la connexion réseau et résout donc le problème. J'espère que cela t'aides.


Juste mes deux cents,

J'ai déjà rencontré ce problème deux fois et il s'avère qu'après toutes les suggestions que j'ai essayées, c'est BitDefender sur ma machine locale qui le faisait. Par conséquent, ma solution à ce problème consiste à essayer d’ ajouter des exceptions au logiciel de sécurité local dans le pare - feu et ses composants audiovisuels . Dites-lui d'ignorer les fichiers msvsmon .exe et devenv .exe et de voir quelle différence cela fait.

Sinon, essayez de l'arnaquer complètement et voyez si cela vous permet de déboguer votre solution.

Vous pouvez voir ici pour plus d'informations: http://forum.bitdefender.com/index.php?showtopic=37028

J'ai installé la dernière version de BitDefender et tout s'est bien passé pour moi.


La seule réponse que j'ai eu à travailler avec VS2012 est d'aller dans les propriétés du projet> Compiler> CPU cible et définir l'option "x86".

Cela semble également lié à cette question: le débogueur ne peut pas démarrer dans VS2012 RC. Ils l'ont également soumis à Microsoft Connect. Semble être un problème de Visual Studio ...

bonne chance.


Solution pour moi dans VS 2015. J'avais une entrée DNS publique mappée sur mon IIS local et l'onglet Web / debug du projet:

<app>.<domain>.co.uk

Il me suffisait d’ajouter cela au fichier hosts en tant qu’hôte local:

127.0.0.1 <app>.<domain>.co.uk

Ainsi, VS ne pense plus que l'hôte est une machine distante.





64bit