Dépendances manquantes lors de la construction de CruiseControl

Question

Le problème est que lorsque les projets sont construits et produits normalement sans erreurs, le dernier msi empaqueté manque des assemblys de dépendances qui sont normalement empaquetés si quelqu'un construit le projet via Visual Studio par exemple. Donc, ce qui se passe, c'est que l'application s'installe normalement, puis se bloque à l'exécution en disant que xyz dll est manquant. D'après ce que je peux dire, il ne rafraîchit pas les dépendances avant de construire le projet d'installation ou ne parvient pas à les inclure toutes.

Nous construisons en utilisant devenv et le fichier de solution (Reconstruire tout)

Quelqu'un at-il rencontré quelque chose de similaire et si oui comment avez-vous résolu ce?

edit: CruiseControl fonctionne dans un maching différent de celui du développement. De plus, nous avons compris que cela se produisait avec des projets référencés dans une solution.

IE dans une solution avec 3 projets, A une bibliothèque, B une application qui référence A et C un projet d'installation puis après la construction ce qui arrive est que B manque A bien que la construction soit réussie et la msi produite.

Answer 1

Cette situation est due au fait que MSBUILD ne prend pas en charge les projets d'installation. Nous sommes donc obligés d'utiliser devenv pour construire la solution avec Cruise Control. Le vrai problème était que les projets de la même solution étaient référencés par l'application principale et bien que cela ne soit pas reproductible dans les projets d'installation .NET, cela arrivait souvent dans les projets d'installation des CF. Nous avons résolu ce problème en changeant l'architecture de nos solutions CF pour avoir tous les projets connexes dans un projet en tant que dossiers de sorte qu'il n'y ait qu'un seul exe produit et empaqueté avec le projet d'installation.Il est à noter que nous n'avions pas d'assemblys manquants lors du référencement d'autres fichiers dll, mais seulement lorsque nous référençons des projets de bibliothèque qui existaient dans la même solution. Après avoir cherché sur ce sujet, j'ai découvert des détails troublants sur ce sujet, qui me montrent que ce bug et l'incapacité de msbuild à supporter le projet d'installation existent depuis 2005 dans les rapports du forum msdn et pas seulement.

Answer 2

Il y a un autre post avec ce qui ressemble à la même question, mais je n'ai pas été en mesure de vérifier si cela fonctionne encore. Vous devriez être en mesure d'inclure une tâche d'exécution pour exécuter la macro créée pour actualiser les dépendances.

https://stackoverflow.com/questions/45593?sort=votes#sort-top

Answer 3

Quand vous dites qu'il se construit bien par Visual Studio à la main, voulez-vous dire sur la même machine? Si c'est le cas, le service cruisecontrol s'exécute probablement en tant qu'utilisateur différent et, en tant que tel, a des chemins d'accès et des variables d'environnement différents, il n'a peut-être pas les droits d'accès au système de fichiers. Si vous voulez dire que ça fonctionne bien sur une machine différente, alors je m'assurerais que ces dépendances existent réellement et que l'utilisateur que le service exécute dispose des permissions pour y accéder. Nous n'avons jamais rencontré ces problèmes, désolé, alors j'essaie juste de deviner quelques problèmes potentiels de configuration de CC.NET.

Answer 4

Vous pouvez vérifier si les DLL manquantes sont dans le GAC sur l'ordinateur de build.

J'ai rencontré un problème il y a quelques mois lorsque le serveur de génération générait une installation avec une DLL de moins que n'importe laquelle des boîtes de développeur. Il s'avère que la DLL manquante était dans le GAC sur la boîte de construction. Pour une raison inconnue, VS2005 a décidé qu'il n'avait pas besoin d'inclure la DLL car elle était dans le GAC - même si nous avons spécifiquement référencé une copie locale de la DLL dans le projet.