views:

689

answers:

3

I looked at this post http://stackoverflow.com/questions/547468/assembly-references-wont-resolve-properly-on-our-build-server but it didn't help the issue.

I am (extremely) new to TFS, and just installed 2010 on a VM. I imported a project and got everything working-ish. I went to create a new build through team explorer, and set it up to build on each check-in. It build's locally just fine, but when it's built on check-in it dies on a 3rd party assembly reference. The reference is not in the GAC, but part of the local references. There is only one 3rd party dll, and the projects only reference each other in the solution.

I have a feeling I'm missing some important step with regards to TFS and references. Any ideas?

EDIT: This a test installation...there is nothing else installed on this box, with the exception of SQL and IIS.

A: 

Use the Assembly Binding Log Viewer to see where the runtime is trying to locate the assembly: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx

Then you are probabyl going to have to fix the assembly reference paths in the project files. My guess is that on your local machine you have the assembly in the GAC and that you are trying to add the reference to the assembly stored in a \lib\ or \references\ folder.

Gabriel Lozano-Moran
A: 
Jason Williams
A: 

I have the same issue and I am also new to TFS 2010.

My project has references on a shared folder "R:\Drop Folder...". It's those references that cannot be resolved by MSBuild.

Notice that my project builds fine when compiling directly in Visual Studio 2010 (instead of using MSBuild) on the Build Server where MSBuild fails to find the required assemblies.

I did a full trust on the shared folder using "Caspol":

   caspol -m -q -ag 1.2 -url R:\Drop Folder\* FullTrust

I did it twice... Once with caspol in "%windir%\Microsoft.NET\Framework\v2.0.50727" And once with caspol in "%windir%\Microsoft.NET\Framework\v4.0.30319" to be sure.

Notice: CasPol v4.0 returned the following message (Not sure if it's relevant for MSBuild): WARNING: The .NET Framework does not apply CAS policy by default. Any settings shown or modified by CasPol will only affect applications that opt into using CAS policy.

I also did skip the strongname key verification on the signed assemblies on the drop folder to avoid any issue, using

   sn.exe -Vr *,f510307097254a31   <= this is my key

I did use first sn.exe from the folder C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\

I did look in the FuseLogVw (Log All Binds to Disk) but didn't see any trace of the non-resolved references ?!

In the Team Build Log, I can see that MSBuild is considering the right paths (I can open the assemblies by copy/pasting the considered path in Windows Exploer) but MSbuild concludes that the path didn't exist ??!!???

Considered "R:\Drop Folder\My.dll", but it didn't exist.

I am out of idea... Could anyone suggest a tip ? Gabriel, if you can help me, I will ask Sven D. to give you a piece of fine chocolate ;)

[EDIT]

  • the Team Build process run with a service account "tfssrvc" and I logged on the server with the same account to test a compilation within Visual Studio.

  • Executing the MSBuild command from a prompt succeeds :

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "C:\Builds\1\MSF Agile Test\Build Core\Sources\My.sln" /p:Configuration=Debug /p:Platform="Any CPU" /m:1 /fl /flp:"logfile=C:\Builds\1\MSF Agile Test\Build Core\Sources\My.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true  /p:OutDir="C:\Builds\1\MSF Agile Test\Build Core\Binaries\\"
    
  • I did copy the referenced assemblies in a folder next to my project, hen MSBuild succeeds in resolving the references.

  • I did this last test: I have added in my project a resource on the shared drive. And then I got the following message from Team Build : 'Error reading the file 'q:\Drop Folder...' -- The system cannot find the path specified. '

So I would conclude that Team Build, even if running with an service account which has access to the shared folder, may not access this shared when doing a build. I did check in the logs and I can however see that the build is well executed by my "tfssrvc" account ?! And when I am logged in Windows with this account, I can successfully run MSBuild in a command prompt...

And the solution: Mount the network drive in the Build Script (so it's mounted by the Build process) or use UNC path. Even if it was mounted with the account used by the Team Build, this last one may one access it because it's not mounted in its "process"