VS.NET and hintpath problems...

In a project we are working with multiple developers AND a build server on a large set of Visual Studio solutions. Problem is that when we have references to a folder with shared assemblies, the relative path to those assemblies specified by a hintpath directive in the .csproj file ends up wrong. The solution file opens up on one system. but fails on another system (reference not found). We also have problems in our automated builds (using the NAnt solution task).

A fix to this is setting a registry entry to the folders with shared assemblies, if the assembly can't be found, this path is checked.

Add a key with any name to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\AssemblyFolders, and set its (Default) value of type REG_SZ to the path with your assemblies.

Published Wednesday, January 19, 2005 11:33 AM by svdoever
Filed under: ,

Comments

Wednesday, January 19, 2005 6:07 AM by Jamie Cansdale

# re: VS.NET and hintpath problems...

There is another way. If you add your referenced assemblies you your project as linked project items (as well as project references), Visual Studio will used the linked assemblies in preference to the HintPath and even AssemblyFolders.

This problem was killing me for a long time. I was in the situation where it would only build on another machine if I checked in the .user files (which is wrong!). I found that adding the assemblies as project items does the trick. In simple cases just drag and drop the assembly into the project, otherwize add them as links.

I hope that makes sense.
Thursday, January 27, 2005 5:06 PM by AndrewSeven

# re: VS.NET and hintpath problems...

Yet annother application of VisualStudio\7.1\AssemblyFolders


Thanks.
Thursday, February 03, 2005 7:50 AM by TrackBack

# SolGen: C# Solution Generator v0.1

SolGen: C# Solution Generator v0.1
Thursday, April 28, 2005 6:42 PM by TrackBack

# VS.NET 2003 Assembly Path References

Saturday, April 30, 2005 11:35 AM by TrackBack

# VS.NET 2003 Assembly Path References

Monday, August 07, 2006 6:00 AM by BbambooWave

# re: VS.NET and hintpath problems...

Great Serge,

Just what we needed for our BizTalk Cruisecontrol build machine.

Thanks

Friday, January 11, 2008 11:30 AM by Mike

# re: VS.NET and hintpath problems...

The easiest solution is to modify the .csproj file in a text editor and change the value of the <HintPath> tag to be static instead of relative.  Visual Studio will not modify the path when the project is reloaded and you will no longer have the problem.

Wednesday, October 08, 2008 7:36 AM by Justin Dahl

# re: VS.NET and hintpath problems...

Thanks Serge,

Exactly what we needed to solve assembly referencing problems on a dedicated system that carrys out automated builds

Friday, January 09, 2009 5:59 PM by amitn

# re: VS.NET and hintpath problems...

Resolving Assembly References at Build Time

At build time, Visual Studio .NET resolves assembly references by searching the following

locations in the following order:

  1. Look for the assembly in one of the project folders. This assumes that you have added the

assembly to the project by using the Add Existing Item menu option. Project folders include any

folder displayed by Solution Explorer (except when Show All Files is in effect).

  2. Look in the folders listed in the ReferencePath attribute of the <Settings> element within

the project user options file. This attribute can contain a comma delimited list of folders.

  3. Use the <HintPath> element in the project file.

  4. Look in a set of folders identified by registry settings. These are the ones that contain

assemblies displayed on the .NET tab of the Add references dialog box. For more details, see

Using the .NET Tab of the Add Reference Dialog Box.

  5. Look for COM Interop assemblies in the obj sub folder beneath the project folder. For more

details, see Referencing COM Objects.

Notice that the reference path in the project user options file takes precedence over the hint

path established when you set a file reference.

Leave a Comment

(required) 
(required) 
(optional)
(required)