Visual Studio 2008 and the CopyLocal setting
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.
Feel my pain
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:
-
<Private>True</Private>
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:
- True
- False
- Um… uh… Other?
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.
Manual repairs
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.
Conclusion
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.
Related Posts
- Visual Studio 2008 and its CopyLocal setting
- 3 Useful Visual Studio Tricks for Spark Templates
- How to avoid Visual Studio Help
- Tools: Firebird Maestro
- Tools: Add In Express
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.
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.
~
[...] http://underground.infovark.com/2009/09/09/visual-studio-2008-and-the-copylocal-setting/ [...]
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
@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).
And the problem is more complicated with test projects, because then you have the testrunconfig’s deployment section to think about too.
[...] http://underground.infovark.com/2009/09/09/visual-studio-2008-and-the-copylocal-setting/ [...]