Don’t you just love it when you google the error and there’s just one single hit? And it’s irrelevant or doesn’t contain a working solve?
I’ve been playing around with the .NET 5 previews for a few weeks now. Looking forward to the november release! C# will get some pretty nice features…
But anyways. I’m using VSCode, which means the C# extension and a standalone Omnisharp/MSBuild thing that I have little to no control over. Until recently, I also had Visual Studio 2019 and 2017 installed, for various work-related reasons. Life was good, everything worked fine.
the reference assemblies for .netframework,version=v5.0 were not found
So not fine then.
Step 1: Realize VSCode suddenly decided to prioritize the MSBuild from Visual Studio 2019, rather than the MSBuild that is part of the C# extension for VSCode. This was apparent from the logs. The 16.7 MSBuild of VS2019 didn’t quite cut it; it apparently has no support for .Net Core 5. 16.8 does, and 16.8 is what’s included in the extension.
Tried using a omnisharp json settings file to manually choose the MSBuild version. Didn’t work. Got fed up, uninstalled VS2019 and 2017 as well for good measure.
Step 2: What the heck is a NuGet fallback folder?
Now the damn thing only had one MSBuild to choose from.
[fail]: OmniSharp.MSBuild.ProjectLoader The "ResolvePackageAssets" task failed unexpectedly. NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder 'C:\Microsoft\Xamarin\NuGet\'.
This led me down a merry chase. I had no idea what a NuGet fallback package folder was or why OmniSharp was suddenly looking for one. Or why it was supposed to be in C:\Microsoft\Xamarin\NuGet\, which seems like a pretty bad place for one.
I had, of course, no problems at all using NuGet or adding new packages to my project. OmniSharp was the only one unhappy.
Things that didn’t work:
- Editing the NuGet settings file to use a different directory.
- Looking for the environment variable said to override any settings in said file.
- Googling the error message.
Thing that did work, but was ugly:
- Creating the folder. It remained empty and was never used. Worked, but I strongly dislike having unnecessary folders in my C root. It felt like a kludge, and I was no closer to actual understanding.
Finally, by chance, I opened another of my old projects – I had tried several at this point; none had worked. This time, it worked!
So I did some testing, and this is what made the error message go away for me:
- Remove the obj folder and allow it to be rebuilt.
That is all.
Do I know what the heck caused the problem? Not really, I haven’t checked deeply into the files in the obj folder to see what made them different. But it works. And doesn’t mean I need to have any weird folders.
So… Hopefully, the next poor sod who tries to google the error will get two hits.
Or it just goes away in november and is never encountered by anyone ever again.
Remove the obj folder and allow it to be rebuilt.
Thank you so much for that.
My manager is waiting for my commit and I have 100 tabs open trying to find something to work.
Just this solved it.
Hi – This worked for me too, deleting the obj folder worked !