3rd party assemblies in TS Build

17 בדצמבר 2006

תגיות: , ,
אין תגובות

Here's something I stumbled upon trying to build a few solutions using the TFSBuild process.



I had a typical solution. It contained some projects, which referenced one another, and a few prebuild assemblies. 3rd party .NET assemblies needed to compile some of the projects in the solution. These assemblies were not in the source control.


Each developer had them on a network drive on his machine. Assemblies like the Janus assemblies, the entlib assemblies which you find in every second project you see and a few other familiar and unfamiliar ones.



The problem here of course, is that these assemblies are not located on the build machine on the same path, and since the build process' service uses a different user name I wanted these assemblies to sit in a predefined directory on the machine.



There are few options to handle this case. One of them is to use the HintPath:


<ItemGroup>


  <Reference Include="System.Workflow.Activities, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">


<HintPath>C:\WINDOWS\Microsoft.NET\Framework\v3.0.00000.0\Windows Workflow Foundation\System.Workflow.Activities.dll</HintPath>


    <Name>System.Workflow.Activities</Name>


    <SpecificVersion>True</SpecificVersion>


    <Aliases>global</Aliases>


    <ExecutableExtension>.dll</ExecutableExtension>


  </Reference>


 


This might solve my problem, but it forces me to keep editing the build file for every assembly that I add.


Another solution could be to use the AdditionalReferencePath, but i won't discuss it here.


<AdditionalReferencePath Include="C:\MyFolder\" />


Another cool resolution to this problem was found after I explored the build process a little.


It turns out that the MSBuild is quite smart, and it looks for linked assemblies in quite a few places before giving up.


The MSBuild is looking for a file with a name of the assembly, followed by an extension of exe or dll in a specific order defined on the targets file


The default search order is this:




  • Files from the current project – indicated by {CandidateAssemblyFiles}. 

  • $(ReferencePath) property that comes from .user/targets file.

  • $(HintPath) indicated in the original proj file

  • Target framework directory.

  • Directories found in registry that uses AssemblyFoldersEx Registration.

  • Registered assembly folders, indicated by {AssemblyFolders}.

  • $(OutputPath) or $(OutDir) of the build project (bin folder)

  • GAC 

  • The reference item include attribute as if it were a complete file name. {RawFileName}

 This order in the targets file can be reconfigured, though this is not recommended.


Take into consideration that for search paths defined in the registry, components in current user are always preferred over components in local machine and that the current framework target version is preferred over older target version



In my case, I edited the registry.


I added a key in "\HKEY_LOCAL_MACHINE\SOFTWARE|Microsoft\.NETFramework\v2.0.50727\AssemblyFolderEx", and set its data to the path of the directory containing my prebuild assemblies.


This did the trick and the MSBuild compiled the problematic assemblies like a charm.


 Roy

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *