views:

72

answers:

2

Hello,

I have issues to build a project using external libraries with Visual Studio 2010 TFS.

At the root of the solution, I have a "libs" folder with all my shared libraries and I'm referencing the libraries from there.

When I'm building the project, some libraries are not considered and I get the following error message:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1360): Could not resolve this reference. Could not locate the assembly "Spring.Data". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

I tried to change the solution configuration from Debug to Release, to locate the shared library in another folder... I didn't manage to go through it.

Any idea on how I could get this library used in the build?

Thanks, David

+1  A: 

The first step is to verify that you're correctly referencing the dlls using correct relative paths. Open the project files' XML and make sure the paths are relative, not absolute ("...." vs. "C:\Code\").

If the paths are all correct the next step is to make sure the files are being pulled down into the build server's Workspace. You can verify that by just examining the build folder on the server. If they aren't there then there's probably a problem with the workspace mappings that define the folders to get when beginning a build.

Those are the most common issues I've seen. If those are correct, you'll need some more diagnostic info.

John Bowen
Absolute paths will kill you every time.
Robaticus
I'll check this point. But at first sight, it looks like it's using the version of the library coming from bin/debug
davandries
Do you mean that you're referencing the dll in another project's bin/Debug folder instead of the one in the libs folder? If so, that's your problem. The compile output folder is different on the build server so your project is pointing to a folder that most likely doesn't exist, or is empty.
John Bowen
No John, I'm not using DLLs from any Bin/Debug project.At the root of the solution, I have a Libs folder with all my libraries. I'm referencing libraries from there, in Visual Studio after a build the properties window display the bin/debug path of my project.The libraries are correctly copied in the Build folder of my Team Foundation Server.
davandries
The only references that should show up as being in a bin/debug path in the properties window are direct references to that folder or project references. If it's not showing the Libs path then it's not pointing to the Libs version of the dll.
John Bowen
I got it working after few verifications of the libraries
davandries
A: 

Check your hint paths. Sometimes there are stale references there...

Maybe I can give a good practice when referencing external libraries:

  • copy your external libraries or compiled stuff from other teams in your company on a development file server in the format:
  • create a copy-script for every solution file and add it as solution item. Add several xcopy commands for every external lib you want from the dev server for that solution file to build correctly.
  • create a script to create a subst virtual drive(with dos command subst) and map this to your workspace, for example the R drive and activate this script on windows startup to get it available at all times. This script is dedicated for the developer and has mapping to the developers workspace.
  • create all file references you have with the R drive mapping in it. For example: R:\NiceLib\1.0\nicelib.core.dll

This way you get your TFS clean, with only your own sources and all compiled stuff from external parties or even from other teams in your company, are stored on the dev file server.

Patrick Peters
How do you handle versioning of the referenced dlls using this method? What happens when you do a branch to try out a newer version of an external assembly or patch an older version of your app?
John Bowen
I checked the hint paths. They look OK
davandries
@John: each external lib must have its version nr in it; once stored on the file server it will be secured for overwriting; in my example when trying out a new version of a lib just create a new subfolder on the dev file server R:\NiceLib\1.0.1\nicelib.core.dll
Patrick Peters