Assembly Reference Resolving in Visual Studio.

I got a question today about a problematic assembly references during a build of a large project.

Visual Studio projects have a user file (*.csproj,user, *.vbproj.user) that stores a “References Path”. You can edit this list of paths in your project properties dialog and it works like a PATH variable.

The twist comes in when you add a reference to a project. The IDE creates a relative formed path to the assembly you picked in the add reference dialog and places that as a “hint path” in the .csproj/.vbproj file.

So imagine you have some carefully crafted hint paths in your project file references, and no references paths in your user file. It's still possible, for your assembly to not be found where you expect it.

Did you know that VS.NET will automatically add References Paths for you as part of it's build process. Let's say you have a list of references in your project. As VS.NET iterates through the list of them one at a time, it will first check the references path. If the assembly is not found, it will use the hint path. If it finds it with the hint path - it will take the fully qualified path to that assembly - and put it in references path of your user file. When it gets to the next assembly it will check all those references paths - including the one it just automatically added.

What happens if you have multiple copies of your referenced dll hanging around? It could find one other than the one you referenced in your hint path.

This is all pretty rare to happen, but if you are like some folks who use Visual Studio itself as your build server (not NAnt) and as a matter of practice you delete your .user files as part of that build (with the predefined reference paths), you could find yourself in hot water. The only solution in this mixed up process is to make sure you don't have multiple copies/versions of your referenced assemblies lying around. Or better yet, use NAnt.