Let\'s say we have a solution with the following structure:
@RenniePet Here's a link to a blog which describes the method RenniePet described in a comment above (if you don't want to edit your project file manually as @Shaun suggested):
http://blogs.msdn.com/b/jjameson/archive/2009/11/18/the-copy-local-bug-in-visual-studio.aspx
One more thing.
When you don't use the referenced DLL in your code at all, it will ignore the CopyLocal and won't copy it to your output directory.
I had a strange situation where even though the assembly was a project reference and was referenced with "Copy Local" showing up as "True" in the reference properties window, the DLL was not being copied to the output directory. I had an earlier version of the DLL in the GAC but I didn't see why this should prevent the DLL being copied.
I found that by unloading the project and manually editing the project reference XML as follows:
<ProjectReference Include="..\SomeProject.csproj">
<Project>{11111111-1111-1111-1111-111111111111}</Project>
<Name>Some Project Name</Name>
<Private>True</Private>
</ProjectReference>
The DLL was copied to the ouput directory as expected. I found that just setting Copy Local to True in the properties window meant the <Private> element was completely missing, but in the case of it being set to false it was present with a value of "False".
Yes, Visual Studio will copy a DLL to the output path in any of the two conditions below:
The reason why it will not copy-local when the file is in GAC, is that when resolving assembly names the GAC has highest priority, i.e. even if you have a (different) local copy, the version from the GAC will be used.
I suggest you set up a library directory where you put all external assemblies that are referenced. Then you set up an automatic MSBuild script on a computer (or VM) that does not have the Oracle-file gac'ed (nor Visual Studio installed for that sake). That way, the file will be copied to the build, and you will have more control over what is done than when using VS.