Weird Visual Studio 2010 Behavior - not copying dlls to bin

Question

I hope someone else has encountered this because its driving me batty.

I recently got a new laptop so I've been setting up my Visual Studio solutions (VS2010 with .NET 4.0) that I saved off my old machine. One of them is a simple console app that I use to simulate some things for testing. It references 2 assemblies that I have in another solution that I am working on now. This used to all work fine as expected but ever since moving to the new machine I get the dreaded "The type or namespace name 'YourAssembly' could not be found (are you missing a using directive or an assembly reference?" error message. The references are clearly shown in the Visual Studio but when the project builds it does not copy them to the bin directory which explains the message. Initially I was just referencing the dlls the way I would any 3rd party dll but I even tried removing that and including the project files in my solution and referencing them that way and still it fails. I've verified that the dlls have their 'Copy Local' property set to true and they do. Its really bizarre because the project references several other dlls that are just 3rd party assemblies (for example NLog, GData, etc) and those all copy over fine but not these two for some strange reason.

Here's one more piece of oddness. If I add some code to the console app that references my assemblies it says it can't find it. If I then re-add the assemblies to the references, the error disappears until I try to build it again and then it returns. Is this a VS bug or what? I've never seen this kind of odd behavior before.

thanks

Answer 1

Hans had the answer above but I was unable to find that post through searches so hopefully if you stumble upon this question I can save you several hours of frustration.

For some bizarre reason the 'Target Framework' was defaulting to ".NET Framework 4 - Client Profile" in the project properties. I double checked and it seems to do that whenever I create a new console app. It must be version related thing in VS because I hadn't encountered this issue previously in 2010.

To fix:

1. Right click on your project, choose properties
2. Under the main Application tab, set the Target Framework to be your framework of choice but NOT one of the 'Client Profile' options
3. Save and build as normal

Answer 2

1. I've also had weird errors like this where the NTFS permissions were set on the old file with an old login, but the new machine didn't like the old permissions.
2. Also, sometimes the old .sln or .csproj file refers to an odd file path that you can't seem to edit from within VStudio. Try opening those files with notepad and make sure the paths aren't broken. You can usually edit and save with fixed paths and things will work again.

Answer 3

One case that I have seen that caused the problems you are talking about:

Including references to dlls that are built in-house, linked to a specific version of the dll. Get a new copy of the dll (with a different version number) and the build breaks.

The solution in this case is to set the DLL reference property Specific Version to false. The version of the dll is ignored (in my case, it is safe to ignore it), and the build works properly.