Though the Microsoft marketing drums have begun beating to the rhythm of Visual Studio 2010, most of us workaday code monkeys are still using Visual Studio 2008. And while VS 2008 is a great IDE for development — especially once you add ReSharper — it has a few configuration quirks that drive me up the wall.
Most of these quirks are hidden from the typical developer and only appear once you try to package and deploy your software. It’s the dreaded Works on My Machine syndrome.
And if there’s one Visual Studio build configuration setting that causes me to scream in anguish, it’s the CopyLocal property.
When you add a reference to another .dll in Visual Studio 2008, some default settings get applied.
The CopyLocal setting on the reference properties panel.
Here’s how the settings look after I added log4net to one of my projects. As you can see, the CopyLocal setting is set to True. Or is it?
If you move your solution to your build server, you might be surprised to find that CopyLocal isn’t actually copying the .dll. I was certainly surprised to find that my builds failing for inexplicable reasons.
It took me a while to figure out that Visual Studio 2008 is a dirty liar when it comes to CopyLocal. Let’s have a look at our .csproj file, shall we? You can load the XML in the .csproj file by following these directions.
Ah, there’s the contents of our csproj file. And there’s our reference to log4net, but…
Where's the CopyLocal setting?
The CopyLocal setting isn’t there! Within the log4net reference, we should see an XML element called Private. It should look like this:
But it’s clearly not there. Uh oh.
And because it’s not there, it might work on your machine but not on other machines. Even though the Visual Studio IDE represents CopyLocal as a Boolean value, it’s actually a ternary value. Where Booleans have two states, usually represented as True/False, Yes/No, or 1/0 pairs, ternary logic has three states:
Yikes! That’s a classic interface failure mode.
It turns out that the default for the CopyLocal setting is… something not quite True and not quite False. If you read the documentation for how to set the CopyLocal property, it mentions the weird logic Visual Studio uses to determine what the “default” should be. Argh.
To fix the problem, we reload our project in Visual Studio again. Then we toggle the CopyLocal setting from “not quite True, exactly” to “False” and then back to “totally, literally True”.
With apologies to the Violent Femmes, when I say CopyLocal, you best CopyLocal, motherf***er!!!
And now it’s really, truly TRUE. Honest. Take a look at our .csproj file now.
This is how CopyLocal=True ought to look.
And there it is, the CopyLocal setting. The way it should be. The way it should have been all along.
I don’t know whether Visual Studio 2010 fixes this problem. I haven’t looked at the VS 2010 Beta release to find out. I’m too busy manually editing all my .csproj files to get our Infovark builds working. But I really, really, really hope that the folks at Microsoft have done something to address the problem.
Here’s the simple interface design rule: If it isn’t a Boolean setting, it shouldn’t look like a Boolean setting.
Unless of course, you want to make the pages of The Daily WTF.
11 Comments
Chris
That’s not all. If you do a project-to-project reference it ignores your setting altogether. I’ve recently updated my solution to include many projects whom’s assemblies live in GAC. Then since they were there I made them project references and changed Copy Local to false. It decided to ignore me and GAC and start copying the assemblies to the projects local folder.
16 Oct 2009 02:10 pm
Florence
that’s really bad and explains a lot of the weirdness i have witnessed with VS 2008. Another thing is that VS really should let you specify what the default should be (in the VS options). if you build your apps in such a way that they require copy local to be false 90% of the time, it’s a real pain to having to change the setting every time.
~
05 Nov 2009 05:11 pm
Upgrading BizTalk 2006 to BizTalk 2009 – Romiko's Blog
[...] http://underground.infovark.com/2009/09/09/visual-studio-2008-and-the-copylocal-setting/ [...]
mota
same in vs2010, referencing dlls in project1, enforcing copy local as described in this article, and when i run project2 with reference to project1, nothing is there, not even in gac, just exception all over screen
18 May 2010 05:05 am
James Barrow
@mota Make sure you have a hard reference to project1 in project2 (i.e. there is a piece of code that uses something from project1 – not just a using statement as far as I know, actual calling code).
06 Jul 2010 04:07 am
James Barrow
And the problem is more complicated with test projects, because then you have the testrunconfig’s deployment section to think about too.
06 Jul 2010 05:07 am
Upgrading BizTalk 2006 to BizTalk 2009 « Romiko Derbynew's Blog
[...] http://underground.infovark.com/2009/09/09/visual-studio-2008-and-the-copylocal-setting/ [...]
Justin James
I can confirm that this issue exists in VS 2010 SP1 as well…
J.Ja
07 Apr 2011 02:04 am
Adam Ralph
Thanks for documenting this horrible muddle. Your post has helped me fixed an issue I’ve been having.
12 Apr 2011 09:04 am
500 and Other Errors in Azure Deployments – Jim O'Neil – Developer Evangelist – Site Home – MSDN Blogs
[...] Bottom line, Copy Local looks like a boolean value in the IDE, but it is really a ternary value under the covers. Without an explicit <private> tag Visual Studio is supposed to do the right thing, but it seems that’s not the case for all. You can read more about this behavior in Jeremy Jameson’s blog and Infovark. [...]
woolie
yep, the CopyLocal bug is still there (comfortably) in VS2010.
just another microsoft screwup.
17 Nov 2011 11:11 am (@Twitter)
Leave a Comment