Scott Hanselman's ComputerZen.com

Hey Scott,

Yeah - I just ran into this at a client's yesterday !

They actually got a big kick out of me showing them (one of) the references in the IL via ILDASM !

See you --

Damn references get added to your user file automatically just by opening the project in Visual Studio. What's worst, is they get added (in various orders) depending upon the order of the references in the csproj file. References don't always get added, but I think when it goes to resolve a referenced assembly, it ignores the hintpath and first checks to see if the assembly exists in any of the other previously searched directories.

For example if you reference A.dll with a hint path of c:\FolderA and the next reference is B.dll with a hint path of c:\FolderB - if B.dll happens to also exist in c:\FolderA, then FolderA gets added as a References path - and C:\FolderA\B.dll is the assembly that is referenced, not the one that would have otherwise been found with the hint path of c:\FolderB.

To make matters even crazier, if you change the order of the references in your csproj file then the reverse happens. Part of the lesson learned is that it's really bad to have multiple copies of assemblies floating around in your solution's folder structure. While you can partly solve that problem by compiling to a common output path, that doesn't work if your assembly get over 64K as there is a locking problem with VS.NET on those. A suggestion there is use a post build event to copy the dll's to a common folder with a batch file. That won't avoid the duplicate dlls, but if you standardize on 1 (or few) common directories where all of your external dll references can be found, then you'll save some serious pain.

Some further clarification. It looks like whenever you open up a csproj file, it adds referencespath's to the user file for each external assembly reference (ref by dll)....in the order that it encounters them in the csproj file. The order of the ReferencesPaths are important since that is how all DLL's are searched...except it looks like the .NET Framework ones which have fully qualified absolute hint paths don't have their paths added to the ReferencesPath of the user file. This may also be because they are in the GAC, but not 100% sure....in any case, they'll be found in the GAC first anyway.

Two comments

1) one way to think about this is to ask yourself, what happens when you add references to projects/dlls from the "My Documents \ Visual Studio Projects" folder? That path resolves to a filesystem path WHICH INCLUDES YOUR USERNAME. Obviously, you don't want a path containing your username checked into source control. Hence, the .user files in the project folder.

2) GAC. The GAC is big pain in the ass in my experience, but the runtime *ALWAYS* looks for references here first. So if the reference exists in the GAC, that's all you'll ever get no matter how many copies of the dll you put on your machine.