Looks like MSVS 11.0 Beta spoiled a MSVS 10.0 installation

Question

I ran into compilation problems with my MSVS 10 after installing MSVS 11Beta. Now, when I compile my C# Projects in MSVS 10 (Projects created in MSVS 10; Target framework: 3.5),

Answer 1

Worked for me: Removing the bin and obj folder for problematic folders and restarting the solution

Answer 2

In my case, I received that error message when trying to build a solution on a 32-bit Windows 7 machine. The way to resolve the error for me was to right-click on the project, choose properties, then go to the Build tab. In here I changed the "Platform target" from "Any CPU" to "x86". HTH

Answer 3

How long is your username?

It seems that there is a bug when the username is 20 characters long. If your username is 19 characters or less it works fine.

I have opened an issue on connect.

Edit: Have you tried setting the environment variable DisableOutOfProcTaskHost to true as suggested in the connect issue, that worked for me.

Answer 4

A similar questin was asked on the MSDN forums. Did you reboot after installing VS11?

http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7d955d96-ff73-47d3-8830-85ea321eb4ab

Answer 5

There is an ugly way to fix the problem: renaming folder "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A". I hate to accept this answer.

Answer 6

This issue occurred for me on my TFS 2010 build server after installing VS2010 and then installing .NET Framework 4.5. This allowed me to build .NET 4.5 projects but any VS2008 project targeting CLR2 (.NET 2.0 -3.5) I attempted to build would return the error. None of the suggestions on the handful of sites talking about this issue worked.

1. Rebooting - Did not fix the issue
2. Setting DisableOutOfProcTaskHost = true in an environment variable and also within the project file - Did not fix the issue
3. Username of my build account was already less than 20 characters
4. Renaming windows SDK folder - N/A since I did not have VS2012 and the 8.0A SDK installed... just .NET framework 4.5.

In any case, to fix this I uninstalled .NET 4.5, repaired VS2010, and then rebooted the build server. Now I am able to build VS2008 and VS2010 projects with no issues.

Luckily I no longer need to build .NET 4.5 projects as that team decided to go back to .NET 4.0.