Nous avons une solution de studio visuelle assez complexe (57 projets, dont 19 qui sont sur un site Web qui ne construisent pas presque à chaque fois lorsqu'il est déclenché en appuyant sur le code, mais nous déclenchons ensuite la construction et sur la tentative qu'elle construit tout à fait. < p> La solution contient 57 projets, dont 19 sont des projets de site Web. (Ce n'est pas des projets d'application Web, il n'y a pas de fichier .CSPROJ.) Les autres sont des bibliothèques de classe et des emplois de base. Les projets de 19 sites Web sont structurés dans des répertoires virtuels IIS dans une gros système de gestion de contenu multifonctionnel.
Le serveur de construction est Hudson v1.395. La commande utilisée pour la construction est la suivante: lorsque la construction échoue, Le fait toujours sur exactement le même projet de site Web, avec exactement le même message: a Recherche Google pour ce message est actuellement moins que utile. Ce lien se rapproche de la question réelle mais n'a aucune résolution. Évidemment, nous ne changeons aucun fichier de solution pendant la construction car il se produit sur le serveur de construction. Quand il échoue, nous déclenchons la construction manuellement et nous obtenons comme nous attendons (désolé, expurgé): < / p> Qu'est-ce qui pourrait provoquer ce message non chargé de domaine d'application? Quelques autres notes: Le problème avec MSbuild est qu'il existe tellement de petites bizarreries qui diffèrent d'une construction dans Visual Studio. Il est extrêmement frustrant pour une solution de compiler dans Visual Studio sur une machine de développeur, puis échouez sur le serveur de construction. Même la production de Msbuild est drastiquement différente (beaucoup plus verbeuse pour une chose) de ce que nos développeurs voient dans leur fenêtre de sortie de construction. Existe-t-il des drapeaux de ligne de commande supplémentaires qui apportent plus que la sortie Msbuild est plus conforme à ce que vous entrez dans la fenêtre Visual Studio Build? Il y a d'autres choses qui sont aussi maladroites. Si vous avez un dossier de solution nommé identique à un projet, Msbuild jette une erreur, mais Visual Studio y traite tout simplement bien. Ce sont les bizarreries qui vous font vraiment tirer vos cheveux.
3 Réponses :
Je ne suis pas si familier avec Hudson ou Projet de site Web (j'utilise des projets d'application de TeamCity et Web), mais je pensais que je voudrais jeter quelques choses là-bas pour voir si cela vous aiderait.
Avez-vous essayé de construire le Solution utilisant MSBUILD directement au lieu d'utiliser Visual Studio? La commande ressemblerait à quelque chose comme ceci: P>
%windir%\Microsoft.NET\Framework\<version>\MSBuild SolutionName.sln /t:Rebuild /p:configuration=debug
En ce qui concerne Msbuild, voir «Modifier 1» que j'ai ajouté à ma question. Bien que pas mon option préférée, je vais l'essayer. Je vais essayer / runexit aussi, bien que nous n'observent pas les instances de Devenv coller sur le serveur. Aussi une clarification - même si elles sont du même référentiel, les deux solutions sont des clones complets, il n'ya donc aucun partage de quelque nature que ce soit entre les deux cas de Devenv simultanés.
En ce qui concerne les niveaux de journalisation sur Msbuild, vous pouvez le modifier à l'aide du drapeau / verbosité Lien MSDN
Cette option n'est pas disponible pour les projets Visual Studio 7.0-9.0 (2003-2008) et C ++! (VS 10.0 Projets convertis C ++ à Msbuild, il est donc possible de y arriver).
Une autre construction simultanée en cours d'exécution à la suite de la même vérification semble être liée. Une ressource disparaît au milieu de ma construction pendant que des courses de construction connexes me rendent méfiant de la construction associée.
Je sais que vous avez dit que vous pouvez les exécuter à la fois manuellement et tout va bien. Cela sent une condition de race pour moi cependant. Essayez de désactiver la gâchette automatique sur les petits projets et de vous engager en tant que vérification finale de santé mentale pour vous assurer que cela ne vous gâte pas.
J'imagine que si vous ne le soupçonniez pas du tout, vous ne l'auriez pas mentionné dans votre message. Règne cela.
J'ai eu un problème avec C ++ Constrations sur Hudson / Jenkins qui est probablement liée, si vous avez deux constructions allant à la fois, les mauvaises choses peuvent se produire.
C'est parce que Hudson / Jenkins dirigera un tueur de traitement pour nettoyer Les processus à la fin d'une construction et Msbuild / VisualStudio partageront des processus courants entre les constructions.
Le problème réel que j'ai eu avec les constructions C ++ s'est manifesté comme une autre erreur: Le problème a été soulevé ici: https://issues.jenkins-ci.org/browse/jenkins-9104 Désactiver le tueur d'arbre de traitement peut résoudre votre problème.