HintPath vs ReferencePath in Visual Studio

Question

What is the difference between HintPath in a .csproj file and ReferencePath in a .csproj.user file? We are trying to fix an agreement in which the dependency libraries are in the svn repo releases, and all projects point to a specific release. Since different developers have different folder structures, relative links will not work, so we came up with a scheme for using an environment variable that points to a specific folder of developers releases to create an absolute link. Therefore, after adding the link, we manually edit the project file to change the link to the absolute path using the environment variable.

I noticed that this can be done with both HintPath and ReferencePath , but the only difference between them is that HintPath allowed at build time and ReferencePath when the project is loaded into the IDE. I'm not quite sure what the consequences of this are. I noticed that VS sometimes overwrites .csproj.user , and I need to rewrite ReferencePath , but I'm not sure what this forces.

I heard that it’s better not to check the .csproj.user file, as it depends on the user, so I would like to aim for it, but I also heard that the HintPath -specified "t" DLL is guaranteed to "load" if one and the other the same DLL located in the project output directory. Any thoughts on this?

Answer 1

According to this MSDN blog: https://blogs.msdn.microsoft.com/manishagarwal/2005/09/28/resolving-file-references-in-team-build-part-2/

An assembly creates an assembly search order. The search order is as follows:

• Files from the current project are indicated by $ {CandidateAssemblyFiles}.
• $ (ReferencePath), which comes from the .user / target file.
• % (HintPath) metadata indicated by the reference.
• Directory of target structure.
• Directories found in the registry that use AssemblyFoldersEx registration.
• Registered assembly folders indicated by $ {AssemblyFolders}.
• $ (OutputPath) or $ (OutDir)
• Gac

So, if the desired assembly is found by HintPath, but an alternative assembly can be found using ReferencePath, it will prefer the ReferencePath'd assembly for HintPath'd.

Answer 2

Look in the file Microsoft.Common.targets

The answer to the question is in the Microsoft.Common.targets file for your target version of the frame.

For .Net Framework version 4.0 (and 4.5!), The AssemblySearchPaths element is defined as follows:

  <!-- The SearchPaths property is set to find assemblies in the following order: (1) Files from current project - indicated by {CandidateAssemblyFiles} (2) $(ReferencePath) - the reference path property, which comes from the .USER file. (3) The hintpath from the referenced item itself, indicated by {HintPathFromItem}. (4) The directory of MSBuild "target" runtime from GetFrameworkPath. The "target" runtime folder is the folder of the runtime that MSBuild is a part of. (5) Registered assembly folders, indicated by {Registry:*,*,*} (6) Legacy registered assembly folders, indicated by {AssemblyFolders} (7) Resolve to the GAC. (8) Treat the reference Include as if it were a real file name. (9) Look in the application output folder (like bin\debug) --> <AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == ''"> {CandidateAssemblyFiles}; $(ReferencePath); {HintPathFromItem}; {TargetFrameworkDirectory}; {Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)}; {AssemblyFolders}; {GAC}; {RawFileName}; $(OutDir) </AssemblySearchPaths> 

For .Net Framework 3.5, the definition is the same, but the comment is incorrect. Definition 2.0 is slightly different; it uses $ (OutputPath) instead of $ (OutDir).

On my machine, I have the following versions of the Microsoft.Common.targets file:

 C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework64\v3.5\Microsoft.Common.targets C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets 

This is with Visual Studio 2008, 2010, and 2013 installed on Windows 7.

The fact that searching the output directory can be a little disappointing (as the original poster indicates), as it can hide the wrong HintPath. The solution is built on your local OK machine, but it breaks when you build in a clean folder structure (for example, on an assembly machine).

Answer 3

My own experience was that it is best to stick with one of two types of assembly references:

• "local" assembly in the current assembly directory
• GAC assembly

I found (just as you described) that other methods are too easily broken or have annoying maintenance requirements.

Any assembly that I do not want to use the GAC should be in the runtime directory. Any assembly that is not or cannot be in the GAC executable directory (controlled by automatic assembly events).

This does not give me any problems yet. Although I’m sure that there’s a situation where it doesn’t work, the usual answer to any problem was “oh, just GAC it!”. 8 D

Hope this helps!

Answer 4

Although this is an old document, it helped me solve the "HintPath" problem ignored on another machine. This is because the reference to the DLL must also be in source control:

https://msdn.microsoft.com/en-us/library/ee817675.aspx#tdlg_ch4_includeoutersystemassemblieswithprojects

Excerpts:

 To include and then reference an outer-system assembly
 1. In Solution Explorer, right-click the project that needs to reference the assembly ,, and then click Add Existing Item.
 2. Browse to the assembly, and then click OK.  The assembly is then copied into the project folder and automatically added to VSS (assuming the project is already under source control).
 3. Use the Browse button in the Add Reference dialog box to set a file reference to assembly in the project folder.