Why doesn't Visual Studio 2012 remember my 'Copy Local' preferences?

Question

I have an application with various references which I upgraded from Visual Studio 2008 to Visual Studio 2010. In that application, the various references have Copy Local set to false in some instances to prevent VS from producing hundreds of 'object already defined' error messages.

That all worked fine in Visual Studio 2008 but after upgrading to 2012 it seems that we can't alter those properties any more. For example, I have an assembly which I want to disable 'Copy Local' on but when I change it to False and click apply, the setting reverts to True.

What am I missing? Is there a new setting in VS 2012 that supersedes that option or something else going wrong?

Edit - Irrespective of the use of 'Copy Local', there does seem to be some odd behaviour. To replicate the issue, start a new console project, add a class library and reference it from the console project. The console project settings show this:

...but the project file says nothing i.e:

The behaviour when nothing is set, however, is that it does copy local:

After switching CopyLocal in the project from false to true and saving the project file it now contains:

...but the GUI always says false!

Answer 1

I've just raised this bug on Microsoft connect.

Answer 2

various references have Copy Local set to false

This cannot possibly be correct, you are talking about the wrong setting. Copy Local plays no role during compilation. It merely ensures that an assembly gets copied to the build directory so you can debug your program. It should only ever be False for an assembly that's stored in the GAC or a project reference. You need it set to True for any other assembly or you can't run your program.

You must be talking about another setting, in VS2008 the "Use in Build" and "Use Dependencies in Build" are relevant to your problem. This is different in VS2012, part of the build overhaul in VS2010.

You get "already defined" compile errors when you violate the One Definition Rule in C++. Which is fairly easy to do in C++/CLI since it gives you two ways to import definitions. The preferred way is through the assembly reference, the compiler imports all the public ref classes from the metadata. ODR is violated when you also import it the traditional way, through a .h file. You very strongly should prefer the assembly reference, the declaration of the class cannot get out of sync with the definition. And you don't get duplicated code in the final program. Also a nasty source of InvalidCastExceptions that are pretty hard to troubleshoot, the class in one assembly isn't identical to the class in another, even if they have same namespace and class name. A strong DLL Hell countermeasure in .NET.

The VS2008 settings are no longer available, you now only have "Reference Assembly Output". Normally set to True so the compiler imports the definitions in the metadata, the preferred way.