Visual Studio 2010 Can no longer build .NET v3.5

I have a 2010 project that is targeting .NET v3.5. Inexplicably I can no longer build v3.5 projects. The project doesn't have ANY references added. It won't even let me add a reference to System.Core as it is added by the 'build system'.

warning CS1685: The predefined type 'System.Func' is defined in multiple assemblies in the global alias; using definition from 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll'

IFilter.cs(82,49): error CS0433: The type 'System.Func' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll' and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll'

Looks like something is grabbing onto 4.0 but I'm not quite sure how to fix it. Any one else run into this?

Coworker had this same issue. It took a reinstall of Windows to correct the problem

I've opened a bug on this one: https://connect.microsoft.com/VisualStudio/feedback/details/558245/warning-cs1685-when-compiling-a-v3-5-net-application-in-visual-studio-2010

If the compiler is set to verbose I see this:

FrameworkPathOverride = C:\Windows\Microsoft.NET\Framework\v4.0.30319

which is defined as:

Specifies the location of mscorlib.dll and microsoft.visualbasic.dll. This parameter is equivalent to the /sdkpath switch of the vbc.exe compiler.

Some other interesting tidbits: I've created a new project all together and cannot build开发者_Python百科 v3.5 at all. I can build 2.0, 3.0, 3.5 Client Profile, 4.0 and 4.0 Client Profile with no problem. VB.NET can build v3.5 but C# cannot. I've tried a reinstall of .NET 3.5, 4.0 and Visual Studio 2010 with no success. Visual Studio debug logs shown nothing interesting and Safe Mode does not work.

Trying to avoid a Windows reinstall...

EDIT: I've come to realize others are facing this issue as well. Link, Link, Link

Reinstalled several times. Visual Studio uninstalls do not clean up after themselves. I've spun up a VM to develop on until I have a chance to reinstall my main OS.

The problem was the caused by the changes made in this post. Forcing the loading of the latest CLR version is what caused the problem. Be careful!

Little cheat: Open VS210 project properties page ob build advanced check do not reference mscorlib.dll. Then in a text editor open the project file and add into the references:

<Reference Include="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL" />

Bye

Here a suggestion:

1. Clean your solution and retry. If no success proceed with step 2.
2. Unload the project by right-clicking on it and selecting the entry "Unload Project"
3. Right-click again and select "Edit Project"
4. Make sure your project targets the correct framework version looking up and setting the value of the following tag:

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

5. Check up the reference list of your project:

<ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.CSharp" />
    ...
</ItemGroup>

Make sure there is no double reference.

I hope this helps.

If not, backup your project files, delete the project and re-add the to a new project. This should most likely work.

I guess there might be a reference to the 4.0 framework in a project or solution file - maybe there are different TargetFrameworkVersion elements. Or maybe some of the files in the bin or obj folder are out of sync.

Try cleaning the solution or even manually deleting the content of the bin and obj folder. If this does not help, just compare the current version with the last working version in Subversion or what ever version control system you are using and you should see, were the change happened.

Per this post on Microsoft Connect, you might be able to solve this by adding a line to your solution or project file setting the ToolPath for the AspNetCompiler to be "C:\Windows\Microsoft.NET\Framework\v2.0.50727".

I've seen this problem many times - the workaround might be very simple.

In my case the offending VS project contained many Virtual Directories (20).

Once this struck again I delete all the Virtuals Dirs then recreated one at a time and rebuilt the project each time seeking this erorr.

When I added two virtuals back to back with NO compilation the error reappeared .

The solution was delete the last VDir, then rebuild , restore Vdirs and then rebuild. Just on of those sneeky quirky things found by methodically repeating a process that can become a "timevamp" or "sunktime" that takes your day, evening, late night and possibly access to a good beer at your local craft brewery.