Visual Studio 2010: Could not resolve mscorlib for

Question

We are currently migrating all our solutions from 2005 to 2010 (that's right, we're skipping 2008!). We are also changing our file structure to make some more sense (some common projects would be nested within specific projects etc etc).

This all means references need to be changed! Apart from that we are also setting them all to .NET 4.0. To accomplish this we've made a temp "GOD" solution with all 117 projects in the same solution.

I am doing this with one co-worker and until about 2 hours ago everything was going according to plan. However we ran into a problem with one of the 117 projects. This project refuses to "display" it's references, resources, services, and settings tabs within the Project Properties.

I get the following exact message:

Could not resolve mscorlib for target framework '.NETFramework,Version=v4.0'. This can happen if the target framework is not installed or if the framework moniker is incorrectly formatted.

Now this is annoying but it gets worse. My co-worker, when getting the same solution from subversion, CAN actually see and change the references and things. As a matter of fact, currently the project actually BUILDS on his machine. He committed the changes but I can't build this specific project, or see the references.

Which leads me to the simple conclusion, something has to be different on my client which is causing trouble! Suggestions online that I've seen are the following:

• Multiple .NET4.0 versions installed (this is not the case on my client)
• .NET v3.5 is not installed; v4.0 is trying to build v3.5 (3.5 is installed on my client)
• The registery key: OnlyUseLatestCLR is set and is screwing things up! (scanned my registry, this key is not present anywhere!)

See: http://connect.microsoft.com/VisualStudio/feedback/details/542789/

The only thing I haven't tried yet which I could do is repair .NET 4.0 how ever I highly doubt this is the issue since we have about 100 other projects which I can edit and build just fine. Both C# and VB.NET.

Answer 1

Microsoft Visual Basic for Applications Extensibility 5.3 (VBIDE) is the name of the devil!!!

Apparently this is a reference which my co-worker had somehow, but i didn't and because of this reference, EVERYTHING died. We discovered this because if you check "Show all files" on the specific project (which is a VB.NET project) you get the sweet References folder, which is normally not there for VB.Net project it's seems. Where the Tab failed us, the folder showed us one reference with a warning. Apparently this is something the compiler or VS2010 couldn't tell me but was exactly what was messing it up for us.

So, if you get this error when working on a project, "Show all files" so you get to see the References folder, and find out which reference could be causing your problems!

I'm glad it found this though, after more then 3 hours!! >.<

Answer 2

Happened to me in the Resource Editor.

Cause: I was importing some .Targets file, which defined a property called AppConfigFile, which probably over-wrote some internal property of the same name:

<PropertyGroup>
  <AppConfigFile>...</AppConfigFile>
</PropertyGroup>

Fix: Renamed property to some other name, and the problem went away.

Answer 3

I had the same issue when the source directory was read only. If I sync my workspace with our version control server (Perforce), it will make all of the directories read only by default unless I select that I am checking out the directory for editing. Sometimes I am lazy and don't do this since I am the only person working on some of these projects at any point in time. But this error goes away clear the read only flag.

Answer 4

I had this problem in Visual Studio 2013 when going from .NET 4.5 to .NET 4.6.2. The problem project was a website project.

Visual Studio automatically runs some tool which generates Reference.svcmap. The Reference.cs starts with:

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:4.0.30319.42000
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

Just picking the new .NET version caused Visual Studio to clean out the generated files and not fill the contents back. I tried all the solutions above but none worked. Eventually I picked .NET 4.5.1 followed by .NET 4.6.2 and the tool did run. The difference in the files was only the version number of the tool which was in a comment, so I could have recovered the files from GIT.

Answer 5

What happened to me was that all my references on my project were lost, so I had to insert them again.

Answer 6

I ran in to this problem today, and it proved to be caused of too long filenames in the project.

This, in turn, was caused by some service references. When a service reference is imported or updated, visual studio generates .datasource files, where the filename is the fully qualified name. This means really long names in some instances.

By googling around, I found hints that it was safe to delete these files. Check this or this out.

Deleting these .datasource files removed the problem.