Nous avons quelques solutions C ++ et nous exécutons des scripts de construction à l'aide de fichiers par lots qui appellent Msbuild.exe pour chacune des configurations des solutions.
Cela fonctionnait bien sur 3 machines de développeurs et une machine de construction, mais l'un des projets a commencé à accrocher lors de la liaison. Cela ne se produit que sur la nouvelle machine qui est un noyau quad, 2,8 GHz, je pense. Il fonctionne sur Windows Server 2003 et les autres sont sur XP ou Vista.
Cela se produit systématiquement même si je modifie l'ordre des constructions dans le fichier BAT.
Si j'exécute la construction de l'IDE sur cette machine, elle ne pend pas.
Des idées sur ce qui pourrait éventuellement causer cela?
J'utilise Visual Studio 2008.
Je vois maintenant que quand il est accroché, les suivants sont en cours d'exécution:
Le fichier EXE existe et le fichier PDB est donc.
Le fichier EXE est verrouillé par un processus et je ne peux pas le supprimer ni le déplacer. Je peux supprimer le fichier PDB cependant.
J'ai aussi le problème si je viens d'utiliser vcbuild.exe.
J'ai décidé d'essayer de déboguer les processus 2 link.exe et les processus MSPDBSRV.exe.
Lorsque j'ai attaché le débogueur / MSDev IDE à eux, j'ai reçu une boîte de message indiquant que l'application était impatiente et / ou que "tous les threads ont quitté".
Je suppose que je devrai vérifier un pack de services pour cette installation MSDEV sur cette machine.
dans le fichier de sortie debug.htm, je reçois toutes sortes de sorties après la commande link.exe est générée.
Toutefois, pour la libération Buildlog.htm, la ligne Linke.exe est la dernière ligne.
Ceci est clairement un pendre dans la liaison. Certainement un bogue Microsoft.
J'essaie maintenant de comprendre le fichier .RSP (Réponse de la liaison).
Quand je publiant:
link.exe @c: \\ version \ RSP00000535202392.RSP / Nologo / ErroreRort: Queue
C'est la dernière ligne dans le journal de construction de libération. L'un de débogage a beaucoup plus d'informations après.
Réinstaller une autre version de Visual Studio n'a pas résolu le problème.
Je vais ouvrir un problème / ticket avec Microsoft. Je vais poster une réponse si je peux.
6 Réponses :
Utilisez-vous XCopy dans vos scripts? Ce suggère d'envelopper xcopy avec cmd / c ".." comme solution.
Si ce n'était pas ça, je recommanderais de réduire les choses en laissant une affaire de processeur (c'est-à-dire retirer / maxcompompt), cela exclut toute forme de condition de race entre les processus de compilation.
Hmm. J'ai une étape post-validation qui appelle un fichier BAT qui fait une copie de * .exe et * .pdb vers un autre répertoire ... cela ressemble à un bon coupable. Je vais retirer ça et voir les résultats.
ne le répare pas. Mais cela ouvre d'autres possibilités pour moi de regarder
J'avais exactement le même problème avec Mme Visual Studio 98, en cours d'exécution dans une machine virtuelle configurée avec 2 processeurs, en supprimant l'un des CPU résolvé le problème
Avez-vous essayé de désactiver la liaison incrémentielle, ou alternativement, forçant toujours une reconstruction de tous?
Je pense que la liaison incrémentielle est éteinte car elle ne peut pas fonctionner avec le député. Je vais vérifier. Ce script fait toujours une propre construction.
Vous pouvez essayer ceci: ouvrez la boîte de dialogue de construction via Menu -> Outils -> Options -> Projets et solutions -> Construire et exécuter
Ici, vous pouvez définir "MsBuild Project Build Verbosité de sortie" à "Diagnostique". Peut-être que cela fournira plus d'informations sur ce qui est Aller mal.
Dans la même boîte de dialogue, vous pouvez définir "Nombre maximum de projet parallèle Construit "à 1. Peut-être que cela fonctionne autour du lien.exe" Hang ".
J'ai défini le parallèle à 1, mais j'essaierai également le diagnostic. Merci
Cela ne fait rien pour moi dans une ligne de commande construite de Msbuild ... à moins que je ne manque quelque chose. Je vais essayer le commutateur Verbose pour la liante.
Msbuild Verbosité n'affecte pas les projets VC ++; ils utilisent vcbilild.
Optimisation de l'ensemble du programme (/ GL et / LTCG) et / MP Ne mélangez pas - la liaison se bloque. J'ai soulevé cela sur Connectez .
Le résultat est que c'est un bogue confirmé dans VS2008; Contactez PSS si vous voulez un correctif; et le correctif est inclus dans VS2010.
Si vous ne pouvez pas attendre que longtemps, désactivez / mp (compile plus lente) ou / LTCG (code plus lent).
Merci. Je vais regarder dans ça. J'apprécie l'aide.
Cela ressemble à une chose de synchronisation. Certains ne font pas. Sur une seule machine, ce sera parfois, parfois ce ne sera pas. La compilation avec CPPUnit semblait la déclencher de manière plus fiable pour nous. Quelque chose à propos de la construction ...
mspdbsrv.exe est utilisé pour combiner toutes les informations de débogage dans un fichier PDB. La version VS2005 de MSPDBSRV.exe est Buggy, il se peut que la version VS2005 présente certaines des mêmes problèmes. Le tuer avant que la construction fait une différence pour certaines personnes. Nous allons l'ajouter à nos constructions aussi bien que nous souffrons régulièrement d'erreurs de PDB inconnues.
J'ai eu un problème similaire, mais avec Visual Studio 2010.
Ceci est un projet qui a fonctionné bien sur un autre ordinateur, mais tout simplement pas mon nouveau. Les symptômes décrits correspondaient au numéro d'origine Visual Studio 2008.
J'ai pu résoudre le problème en installant le Service Pack de Visual Studio 2010 1 (SP1)
http://www.microsoft.com/download/fr/en/ Confirmation.aspx? id = 23691 - ou juste aller à Microsoft et recherchez "Service Studio Visual Studio 2010 1"
J'avais exécuté ma Windows "Vérifier les mises à jour" et j'avais pensé que j'avais installé tous les services de service, mais apparemment, je n'avais pas installé de packs de service Visual Studio.
Après avoir installé le VS2010 SP1, je n'ai plus eu ce problème. J'ai confirmé que j'avais installé VS2010 et le Service Pack 1 sur d'autres ordinateurs plus anciens avec le projet de travail un moment.
Avez-vous envisagé d'attacher un débogueur et de voir où il semble être suspendu?
Attacher un débogueur à tous les processus CL et MSBUILD et LINK.EXE? Je ne pense pas que ce serait un exercice amusant ou productif. Je devrais me casser à chacun et essayer de déboguer et étant donné qu'il s'agit d'un processeur multi-fondamental, ce serait un cauchemar. À moins que je manque quelque chose ...
Mon mauvais, je pensais que c'était link.exe qui était suspendu. L'attachement à 6 processus n'est probablement pas un exercice utile. Considérez cela un dernier recours. :) Peut-être utiliser procmon ( TechEnt.microsoft.com/en-us/sysinternernals/ bb896645.aspx ) aiderait à réduire le processus exact qui provoque la suspension.
J'ai essayé cela, mais pas sûr que le code ASM était utile - le débogueur m'a donné des messages étranges sur les threads déjà sortis ...
Êtes-vous sur VS2008 avec ou sans SP1? J'ai remarqué que la logique multi-caresses du processus de construction a changé après que je suis amélioré à SP1.
Installé SP1 - ne le réparait pas.
@Richb, s'il vous plaît ne modifiez pas mes messages et de les descendre en même temps. C'est vraiment enfantin. Vos modifications coïncident exactement avec le temps des avotes sur ma question