J'ai ajouté à ma solution via Nuget The AutouMapper et Nunit Packages et ils fonctionnent bien et le projet compile sur mon ordinateur.
Lorsque j'ai déclaré le serveur de construction pour construire cette solution, j'ai reçu ce message: p>
[MSBuild] AutoMapper\AutoMapperSpike.csproj: Build default targets (1s)
[10:35:50][AutoMapper\AutoMapperSpike.csproj] ResolveAssemblyReferences
[10:35:50][ResolveAssemblyReferences] ResolveAssemblyReference
[10:35:50][ResolveAssemblyReference] Primary reference "AutoMapper".
[10:35:50][ResolveAssemblyReference] C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360, 9): warning MSB3245: Could not resolve this reference. Could not locate the assembly "AutoMapper". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
[10:35:50][ResolveAssemblyReference] For SearchPath "{HintPathFromItem}".
[10:35:50][ResolveAssemblyReference] Considered "..\packages\AutoMapper.2.2.1\lib\net40\AutoMapper.dll", but it didn't exist.
3 Réponses :
Vous devez vérifier les paquets dans votre VCS ou - mieux - Activer la restauration de package Nuget dans votre solution.
Je recommanderais de tenter de définir la variable de l'environnement à l'intérieur de vos fichiers de construction ou .CSPROJ. Voici l'article de blog sur la raison pour laquelle cela s'est passé et sur quoi définir votre serveur de machine de device / Build. < / a>
Hey, j'ai essayé de définir cette variable d'environnement sur le serveur de construction sans succès. C'est le même problème qu'avant.
Obtenez-vous la même erreur que précédemment, ou une modification de l'erreur?
Même erreur. Pour l'instant, j'utilise une bibliothèque tierce partie dans des éléments de solution jusqu'à ce que je trouve une solution à ce problème. Je veux travailler avec Nuget aussi longtemps que cela ne causera de problèmes dans la construction de la construction.
Nous avons eu un problème comme celui-ci et cela a été résolu avec cela. C'est pourquoi je l'ai suggéré. Probablement dans votre cas, il manque quelque chose de plus. Je suis désolé de ne pas pouvoir identifier cela.
Ajout du EnaBenugetpackagerestore = true variable d'environnement a fonctionné pour moi sur notre serveur de construction (TeamCity 8.0.2 sur Windows XP, de toutes choses). Je devais redémarrer le service d'agent de construction, avant de commencer à travailler. Si votre agent est exécuté sur une autre machine sur votre serveur, vous devez le faire pour chacun, je soupçonne.
Assurez-vous que TeamCity télécharge réellement le paquet. Vous pouvez voir que dans l'historique de construction sur une page de résultat unique, sur l'onglet Packages Nuget. Si vous voyez votre colis là-bas, alors TeamCity est d'accord avec le colis.
Ensuite, assurez-vous de pouvoir construire votre projet à la sortie de la VCS, c'est-à-dire un clone propre et essayez de le construire comme tel, car c'est ce que TC doit faire.
Mon problème dans un scénario très similaire, c'est que je venais de copier un projet dans un référentiel d'anthers et des références où la compilation réussissait localement en raison de la DLL mis en cache: s. Désinstallation du package et l'installer à nouveau à partir du gestionnaire de packages Visual Studio résolue le problème.
Le clonage propre a révélé mon problème. Beau bout.
Avez-vous vérifié les paquets eux-mêmes?
Les packages.config et tous les projets avec des références de projet (y compris la DLL ajouté par Nuget) sont enregistrés.
Le fichier existe-t-il réellement ou non?