"The dependency whatever.dll cannot be copied to the run directory because it would conflict with the dependancy...
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:
<Reference
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:
<VisualStudioProject>
<CSHARP LastOpenVersion = "7.10.3077" >
<Build>
<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.
About Newsletter
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.
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.
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 --