This post originated from an RSS feed registered with .NET Buzz by Scott Hanselman. Original Post: "The dependency whatever.dll cannot be copied to the run directory because it would conflict... Feed Title: Scott Hanselman's ComputerZen.com Feed URL: http://radio-weblogs.com/0106747/rss.xml Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios. Latest .NET Buzz Posts Latest .NET Buzz Posts by Scott Hanselman Latest Posts From Scott Hanselman's ComputerZen.com

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)