Cruise Control .NET ignore les dépendances de projet

Question

J'utilise CC.Net avec succès depuis un certain temps, mais maintenant j'ai un problème. J'ai ajouté une nouvelle solution à CC. Il est compilé correctement dans VS2008, mais échoue dans CC. La raison principale est que les projets en solution sont construits dans le mauvais ordre, sans tenir compte des dépendances. CC essaie juste de les construire dans le même ordre que sur le disque (ordre alphabétique). Par exemple, en solution il y a des projets Proj1 et Proj2, Proj1 fait référence à Proj2. Sur CCNET Proj1 est construit avant Proj2 et renvoie l'erreur "CSC: erreur CS0006: Le fichier de métadonnées" D: \ xxx \ Proj2 \ bin \ Debug \ Proj2.dll "est introuvable". Je sais que cela peut arriver quand le devenv est utilisé pour créer des solutions, mais j'utilise MSBuild. Le code suivant est responsable de la construction:

<exec> 
    <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable> 
    <baseDirectory>code\src</baseDirectory> 
    <buildArgs>/p:Configuration=Debug /t:Rebuild PM.sln</buildArgs> 
    <buildTimeoutSeconds>1200</buildTimeoutSeconds> 
</exec> 

Qu'est-ce que je fais mal?

Answer 1

L'erreur Metadata file could not be found: Quand il m'est arrivé, c'était parce qu'il y avait un fichier appelé proj1.exe à cet endroit qui n'aurait pas dû être là. Ainsi, quand il a utilisé proj1.exe comme référence (au lieu d'un proj1.dll), la référence de proj1.exe à un System.EnterpriseServices.dll local a échoué. Cela m'arrivait avec proj1.exe référençant System.EnterpriseServices.dll qui référencé System.EnterpriseServices.Wrapper.dll. Où proj1.exe n'était pas censé être inclus dans la construction, mais quelqu'un avait nommé un projet d'application de test unitaire contre nos conventions d'équipe.

Je recommande donc de vérifier les références dans les fichiers du projet (décharger le projet et éditer le projet dans vs2010 ou ouvrir chaque fichier projet avec un éditeur de texte ou xml) pour être sûr qu'elles sont ProjectReference pas Reference. Essayez également de faire la construction avec /v:d dans la liste buildArgs pour obtenir un journal de construction plus détaillé qui vous montrera où les fichiers ont été résolus et dans quel ordre. Une autre référence résolue avec succès pourrait être en train de charger x.dll qui référence directement votre D:\xxx\Proj2\bin\Debug\Proj2.dll mais échoue.