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.
It could be that the path to your solution is too long:
Meaning:
C:\MyProject\Folder\SubFolder...
should be Under "256 Character".
http://wcfvs.blogspot.com/2011/04/could-not-resolve-mscorlib-for-target.html
I found this thread when I had the same issue but had no reference issues. I found the link above and it solved my problem. Hopefully this will help someone else who comes here with the same problem.
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!! >.<
I was getting this error this morning. I just did the following:
- Rebuild the Project
- Closed Visual Studio
- Re-opened Visual Studio
and the error was gone.
i worked on my project saved the work and closed visual studio 2010. when opened again for working i got this error i just closed visual studio again copied the file where my project was saved and i pasted it somwhere else (in a file on my desktop) and i opened again the project with VS2010 and it was working.
I had the same issue with a (web) service reference in my project. Both "Update service Reference" and "Configure Service Reference" did not work anymore.
Well lets just throw the (web) service reference away and create it again. No go! Same error message.
Solution: Edit the project file and remove everything which has to do with service references.
Instructions:
- Go to the Solution Explorer and right click on the project name and select "Unload project".
- Go to the Solution Explorer and right click on the project name and select "Edit YourProjectName.proj"
- Remove every element with has something to do with your (web) service references. (Typically it contains text "service references")
- Go to the Solution Explorer and right click on the project name and select "Reload project".
- Now add your (web) service references again.
Problem solved (Well it was in my case).
My guess of what could have happened: I changed a class somewhere in my web service. The interface was not changed and Visual Studio somehow does not see the change(s). The (cached?) configuration does not match anymore and configuring/rebuilding/deleting the (web) service fails.
I had the same issue and after try most of the above, including reinstalling .Net 4.0 and rebooting still didnt go away.
Eventually solved it by moving my project tree lower down. ie. closer to the root of the drive. Turns out the directory and filenames were too long and I believe the references were being truncated and therefore couldnt resolve.
Problem came right immediately.
I had this problem today and the solution was to manually edit the Resources.resx file manually.
My Resources.resx file looked like this:
<data name="SomeString" xml:space="preserve">
<value>I am a string</value>
</data>
<assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<data name="MyLogo" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\MyLogo.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
<data name="Open" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\Open.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
Turned out that Visual Studio didn't like the two <data> elements after the <assembly> element, which is strange considering the fact that Visual Studio added them there itself. My problem was solved after I moved them before the <assembly> element:
<data name="SomeString" xml:space="preserve">
<value>I am a string</value>
</data>
<data name="MyLogo" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\MyLogo.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
<data name="Open" type="System.Resources.ResXFileRef, System.Windows.Forms">
<value>..\Resources\Open.png;System.Drawing.Bitmap, System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</value>
</data>
<assembly alias="System.Windows.Forms" name="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
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.
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.
Check that the target framework in the project properties is set correctly - by default this is ".Net Framework 4.0 Client" - it may be that you require ".Net Framework 4.0"
see this thread that looks like the same issue
you may also want to review this article which relates to debugging an issue with the same symptom using reflector
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.
What happened to me was that all my references on my project were lost, so I had to insert them again.
for me, just setting Target Framework 4.0 resolved my problem. Sometimes the target framework is clear somehow. That might cause problem.
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.
I was migrating a vb.net project to VS 2015. I also had the same issue. The problem is not with the .Net framework, since I was able to create a new Project targeting the specific Framework Versions and it succeeded.
In my case, the project was referencing FPSpreadADO and some other similar libraries. It worked fine once I removed those references.
I had a similar error in XamarinForms PCL project.
I found out that the error was about a reference of the project. I updated the xamarin.forms to the last version and for some reasons NuGet was not able to remove all references of the previous version from the project file (xml).
So, simply I deleted the following line from the project file and it worked!
<Error Condition="!Exists('..\..\packages\Xamarin.Forms.2.3.1.114\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\Xamarin.Forms.2.3.1.114\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets'))" />
Hope it helps someone...
I got this error too. ("Could not resolve mscorlib for target framework '.NetFramework 4.5.1'. This can happen if the target framework is not installed or if the framework moniker is incorrectly formatted.").
This happened when I changed the framework from 3.5 to 4.5.1 on a VB 2013 project. The solution was to remove all the references on the .vbproj file: all the references labeled Reference and COMReference groups.
Of course just after doing this all kind of other errors appeared on the project.
Then I started to copy them back, one by one in the same place, copying from a back-up in order to identify which between them were the problematic ones (I copied the ones related with the new errors I got in order to fix them), refreshing the project each time until the affected window visualized properly.
It resulted they were some customized libraries references which created this problem. I hope this could help someone. Cheers!
A Developer.
I ran into this issue today in Visual Studio 2017 on a project that I had apparently started out as a Universal Windows Platform application but ultimately settled on a Windows Forms desktop application.
Somehow, either through a branching mistake or commit problem in source control, some of the obsolete/discarded UWP XAML files, along with a "project.json" file wound up back in my project folder. VS would no longer build or launch my Windows Forms app with a similar error as reported by others above (e.g., "Could not resolve mscorlib for target framework '.NETFramework,Version=v4.7'").
After deleting all of the obsolete UWP junk (including "project.json", all the XAML files, and any other related nonsense) out of the project folder and reloading the solution, the errors went away and the project both built and launched successfully.
Hope this helps.
In most case it happened because of missing reference.
In solution explorer --> Reference -- > you can see the missing reference (in yellow)
just add the reference you will be fine.
Ran into this today.
Deleted bin & obj folders.
Reopened Visual Studio and it suddenly worked.
来源：https://stackoverflow.com/questions/5498624/visual-studio-2010-could-not-resolve-mscorlib-for-target-framework-netframewo