Scott Hanselman

"The dependency whatever.dll cannot be copied to the run directory because it would conflict with the dependancy...

July 09, 2004 Comment on this post [4] Posted in ASP.NET | Bugs
Sponsored By

This is always a lovely error to get:

"The dependency whatever.dll cannot be copied to the run directory because it would conflict with the dependancy..."

And again, it all comes down to knowing the places to look.  If you open up the .csproj (or .vbproj) files you'll often see something like:

 Name = "Corillian.Voyager.Thingie"
 AssemblyName = "Corillian.Voyager.Thingie"
 HintPath = "..\..\..\build\bin\Corillian.Voyager.Thingie.dll"

And assume that the HintPath is the place that VS.NET looks to resolve the reference.  But, it's only a hint to the IDE.  Often you'll have a situation where a project builds fine on one machine but not other, then the real evil resides in a file that you don't (shouldn't) check into source control and share, the .csproj.user file.  In that file you'll find something like:

    <CSHARP LastOpenVersion = "7.10.3077" >
            <Settings ReferencePath = "C:\Dev\VoyagerThingie\source\lib\Voyager\; C:\Dev\VoyagerThingie\source\lib\log4net\; C:\Dev\VoyagerThingie\build\bin\" >

What tends to happen is that folks forget about these files, and as versions change schmutz can creep into these files.  So, when debugging bizarre reference problems, remember to check out the .user file! (or delete it and build it up again)



About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
July 09, 2004 15:46
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 --
July 09, 2004 19:38
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.
July 09, 2004 23:09
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) 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% any case, they'll be found in the GAC first anyway.
July 11, 2004 2:17
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.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.