TFS Build 2013 - 无法解析主要参考

Question

I'm evaluating TFS Build 2013 for use in a corporate environment. TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.

I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.

I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:

C:\\Program Files (x86)\\MSBuild\\12.0\\bin\\amd64\\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".

So a bit of back of background on how we store and use references: We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).

Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\\References\\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.

So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.

Crucially (it would seem) the first line reads:

For SearchPath "{HintPathFromItem}". Considered "..\\References\\XYZ.dll", but it didn't exist.

Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.

So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\\References" folder setup, or is there something else?

I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.

Thanks

UPDATE:

The build agent is configured as follows:

Build Agent- working directory:

D:\\BuildAgent\\$(BuildAgentId)\\$(BuildDefinitionPath)

The build definition "Source Settings" have the (I assume) default values of:

Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)

Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:

The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:

D:\\BuildAgent\\1\\ClientName\\SolutionName\\src\\Dev\\Evolution\\Source\\SolutionName.Solution\\References

If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\\path\\to\\Solution.sln" then it builds successfully with no warnings or errors.

Answer 1

Well it turns out this wasn't a fault with TFS at all...

The problematic DLL, although present in the References folder, was not actually checked into TFS.

Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.

So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.