2015-03-06 1 views
0

Nous avons SQL CLR dll que nous avons développé il y a assez longtemps que nous avons utilisé. Malheureusement, il n'a jamais existé dans nos builds quotidiens habituels. Nous allons mettre à jour notre serveur sql de 2008 R2 à 2014. J'ai donc ouvert le projet et l'a mis à jour vers un projet de studio visuel 2013 (nous ne l'avions pas ouvert pour parfois). Je mets également à niveau le framework cible de 3.5 à 4.5.1. Enfin, j'ai changé la version du serveur SQL cible en 2014. J'ai pu le construire localement. J'ai ensuite essayé de l'ajouter à notre build TFS et obtenu l'erreur suivante:msbuild erreur de construction sql clr dll dans TFS

E:\Builds\8\TRSApps\Dev\Sources\Shared Objects\Components\FrsSqlCLR\VB Code\FrsSqlCLR.vbproj (76): The imported project "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\SqlServer.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

j'ai pu résoudre le problème. J'ai recherché "SqlServer.targets" localement et l'ai trouvé sous le dossier de framework .net 3.5 (pas sous 4.x): C: \ Windows \ Microsoft.NET \ Framework \ v3.5

Je viens de le copier à l'endroit où il cherchait ci-dessus et il a résolu les problèmes qui me conduit à mes questions:

  1. TFS recherche SqlServer.targets dans l'emplacement correct? Si oui, pourquoi SqlServer.targets n'est-il pas là?
  2. Y at-il quelque chose que je dois installer sur la machine de construction?
  3. Pourquoi le fichier dans le dossier 3.5 cadre et non dans le dossier cadre 4.x

Bien que j'ai pu le résoudre en le copiant dans le dossier 3.5-cadre, il semble une sorte de solution aki. Je veux les détails si à l'avenir quand nous améliorons notre serveur de tfs j'ai tous les détails.

Répondre

1

Vous devez installer Visual Studio 2013 sur le serveur de génération. Aussi Sql Server Data Tools pour 2013.

Une fois que vous les avez sur le serveur de construction, il devrait être construit tel quel.

+0

Bien que je suppose que c'est la bonne réponse ce n'est pas vraiment une bonne solution. Devoir installer Visual Studio 2013 et SSDT sur le serveur de build est une sorte de solution hacky. Et si vous utilisiez TFS en ligne? Microsoft a vraiment trouvé une meilleure solution. Idéalement, vous ne devriez jamais avoir à installer quoi que ce soit de ce genre sur les serveurs de build. – coding4fun

+0

Non, ce n'est pas hackie. Vos serveurs de build doivent refléter vos environnements de développement. Tout ce que vos développeurs doivent construire localement est ce que vous devriez avoir sur l'agent de construction. VSO (TFS en ligne) a tous ces bits pré-installés pour vous. –