2

TFS (2012) Build is checking C:\Windows\Microsoft.NET... for a few of my project references even though the dlls are included as project references (set to copy local) in a folder I'm checking in.

Building outside of TFS, both in VS and using MSBuild.exe command line succeeds.

I can see in the errors and warnings that the references it is complaining about not being to find 'Could not resolve this reference. Could not locate...' are all due to it simply not checking in the checkin dependency folder as defined in the proj file.

Any ideas on how to correct this?

ajeetdl
  • 1,254
  • 1
  • 13
  • 17
  • 1
    Check a) ReferencePaths set in your csproj and b) turn on your msbuild logs to diagnostic and check where this reference is originating from. – allen Feb 11 '13 at 15:24
  • see this post for similar issue and resolution: http://stackoverflow.com/questions/13463205/visual-studio-executes-something-when-i-try-to-build-it-how-do-i-find-out-the-c/13463347#13463347 – Jay Walker Feb 11 '13 at 16:42
  • are you referencing specific assembly versions? Right click a reference and select Properties make sure the "Specific version" flag is True, defaults to False. – rob Mar 15 '13 at 10:27

1 Answers1

2

I believe there is a "check gac first" rule for DotNet dependency resolution.

So I do my references like this.

\MySolution.sln
\BALLayer\Biz.csproj
\DALLayer\Data.csproj
\PresLayer\MyWebsite.csproj
\ThirdPartyReferences\
\ThirdPartyReferences\SuperCoolDll111.dll
\ThirdPartyReferences\SuperCoolDll222.dll
\ThirdPartyReferences\SuperCoolDll333.dll

This way, all csprojects reference the needed dll(s) with a relative path. All cs projects reference the SAME dll.

This has helped me avoid the "I'm gonna look in the GAC no matter what you want me to do" issue.

Nuget does this similarly.

\packages\
\packages\repositories.config
\packages\SomeLibrary\SomeDll.dll
\packages\SomeLibrary\MyNugetDll.dll

and cs projects reference the same .dll with a relative path.

............

Footnote: Open up your .csproj file(s) in notepad, and look for the HintPath. Mine always say something like

<Reference Include="MyNugetDll.dll>
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\packages\SomeLibrary\MyNugetDll.dll</HintPath>
</Reference>

OR

<Reference Include="SuperCoolDll333.dll>
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\ThirdPartyReferences\SuperCoolDll333.dll</HintPath>
</Reference>

.........

But I think the crux of your issue is "copy local" and the "gac first" rule.

.........

PS

Here is another question that discusses the order...better than I could.

In what order are locations searched to load referenced DLLs?

EDIT::::

So lessons learned:

  1. If you have your third party references checked into source control, and the build machine says "i cannot find xyz.dll", then make sure that dll is actually in source control. There are alot of "voodoo" paths on (the local development) machine with visual studio installed, and subsequently will NOT be on the "build machine".

  2. If you use nuget and you check in your dlls, make sure they are all checked in. You might add a new entry to the packages.config and then forget to put the actual dll(s) into source control.

  3. There are some ways to use nuget that you only put the packages.config in source control, and not the third party dlls. Check the comments of this post for articles about that.

Community
  • 1
  • 1
granadaCoder
  • 26,328
  • 10
  • 113
  • 146
  • Hey thanks for answering. My hint paths are set up similarly. Actually I believe Nuget has been used because they are in the packages configuration as you describe in your footnote. That said, they still aren't being checked when run on TFS 2012. If there is a gac first rule then should it not continue checking the paths in the proj file should they not be found there first? – ajeetdl Feb 11 '13 at 15:16
  • Ok...that's slightly different. I gotta dust off my "how does the local build get files ~defined in repositories.config". Hold on. – granadaCoder Feb 11 '13 at 15:28
  • http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html I think you need a command to "go get nuget stuff" in your build script. – granadaCoder Feb 11 '13 at 15:29
  • 2 more "helpers" http://blog.dantup.com/2011/05/setting-up-nuget-to-automatically-fetch-packages-when-deploying-to-appharbor-without-storing-binaries-in-source-control http://nuget.codeplex.com/wikipage?title=Enabling%20Using%20NuGet%20Without%20Checking%20In%20Packages%20Folder – granadaCoder Feb 11 '13 at 15:32
  • Thanks a lot but I don't think Nuget fetching is the problem. All of the Nuget package dlls are being checked in along with the project. They are definitely there. I can see them, it's just that the build system is not looking for them there. Every reference is in the project file has a hint path like so: ..\packages\Microsoft.AspNet.Web.Optimization.1.0.0\lib\net40\System.Web.Optimization.dll – ajeetdl Feb 11 '13 at 15:38
  • Ok. Like, if it were me, I would NOT check my binaries into source control, and allow them to be downloaded at build time. ( http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages#Using_NuGet_without_committing_packages_to_source_control ) To me, source control should contain source, not binaries. But sometimes I violate my own rule........on smaller projects, and check them into source control. But wow, after a few internet articles, this is a mini-can-o-worms....nuget and build system, etc, etc. – granadaCoder Feb 11 '13 at 15:56
  • Hi granadaCoder, I've resolved the issue and it was quite a silly problem on my end. Somehow a few select libs were not added to tfs. Some were, some weren't. So it built locally with both VS and MSBuild.exe but the build copied into the build controller on tfs was missing the files. I don't know how this originally occurred other than tfs auto exclusions suggested they shouldn't be included and someone okayed it. You are quite right with your comment above, this is a can of worms. Thank you so much for your all your help. – ajeetdl Feb 11 '13 at 16:23
  • Since this answer helped me get to the solution I will mark it as correct even though it was not exactly the reason in the end. – ajeetdl Feb 11 '13 at 16:23
  • ..\packages\Microsoft.AspNet.Web.Optimization.1.0.0\lib\net40\System.W‌​eb.Optimization.dll So are you able to make sure the files (and their locations) match that hint path exactly....(relative to the .csproj files). Because that's weird. If the hint path is correct and there's not an extra or missing "..", then it should work. – granadaCoder Feb 11 '13 at 16:31
  • I just read your conclusion. Yeah, I've had that happen. I ~thought the local file was there, but it wasn't.....because there were so many third party files. But it was a good exercise, none-the-less. I ~just started using nuget, and I have to get nuget to work with CruiseControl.NET, and I want to do it without checkign the binaries into source control. So this was a good exercise for me as well. Glad you got it resolved! – granadaCoder Feb 11 '13 at 16:33
  • For future readers. The best way to do this now is to ONLY check in "packages.config" into source control. do NOT check in any dependency dlls into source control. then run the command-line version of nuget.exe and the "restore" command on the .sln. This will force nuget to download all the dependencies. nuget has its own caching system...so only the first time is really bad. Here is the command line link : https://docs.nuget.org/ndocs/tools/nuget.exe-cli-reference#restore – granadaCoder Sep 22 '16 at 15:58