Closed nkolev92 closed 2 months ago
@Tadimsky
Do you still have a machine where this never worked?
Can you look for the Microsoft.EntityFrameworkCore.Abstractions package location on disk and post that enumeration? I'd like to figure out how this happened in the first place, why the libraries section doesn't contain the assemblies in the first place. Did you do any specific actions when you ran into this problem?
The reason why you need to delete the assets file is this https://github.com/NuGet/NuGet.Client/pull/1785.
It's a known gap. I've created an issue specifically for that, but note it's an analysis. https://github.com/NuGet/Home/issues/7000
From @Tadimsky on June 7, 2018 22:42
Hey @nkolev92
I do not have it anymore, but I'm thinking I could just restore the assets file and it would break again? How would you like me to find the package location? I was just using Windows Search before. It was showing up in the package cache, the dotnet sdk store folder and the Nuget Fallback location (also under dotnet).
No, all I did was try and build the project on the other machines - 3 machines worked and 3 didn't. On one of the machines I was getting the same error but for Microsoft.CSharp v 4.5
@Tadimsky Personally I use a tool called "everything" for things like this.
All 3 enumerations would been great. Depending on the type of project, different locations are used (non-.NET Core projects won't use the SDK Fallback Folder)
I'd imagine it works now on all machines if you try to restore again, as I'm suspecting it's either an extraction or a setup problem.
From @Tadimsky on June 7, 2018 23:23
Here is some more information we found:
So it looks like it's just not restoring the package correctly? There is no DLL for the library.
NuGet itself doesn't write to the Fallback Folder but merely reads from it.
Basically the root cause here is the assembly for that package is not in the lib folder on the broken machine.
Looks like something could have gone wrong during setup?
// cc @rrelyea @livarcocc
@Tadimsky, how are you installing the SDK in the machine that fails? is it consistent?
@livarcocc this happened on 4 separate machines. We all installed the dotnet 2.1 sdk from here: https://www.microsoft.com/net/download/windows
It worked on 3 of our machines (funnily enough all Surface Books).
@Tadimsky did the first run experience run on all of them? Are all machine windows machines? x86 or x64?
It's possible that the first time dotnet
was used after installing it didn't run as Admin (there is a message that pops up). I then ran it as admin to unpack.
Maybe the machines were it worked first were run as admin the first time.
Otherwise Windows 10 x64
@livarcocc Anything else you need from me?
Not really, but I can't repro it. So, I am not sure what is going on. Can you repro this 100% of the time with the steps above?
Also, why didn't the cache get expanded when you first installed it? Are you using the MSI to install the SDK?
I haven't tried to repro it end-to-end. Putting the invalid project.assets.json
file causes the issue for me though. But the issue is more how it got into this state (because the package wasn't expanded on disk).
This was installed with the MSI, yes.
The only thing I can think of is that dotnet
ran under Admin console the first time on the machines where it worked and not so where it didn't.
I know that's the difference between my Surface Book (where my command prompt is set to run as admin) and my desktop (where it's not).
Maybe it was halfway through setting up the local cache?
If on all machines this was installed through the MSI, that means that the cache expansion ran as an Admin, as we do that during the MSI installation.
Ah, ok. What is the process that runs when you first run dotnet
after installing a new version of the SDK?
This is the message I mean:
λ dotnet build
Permission denied to modify the 'C:\Program Files\dotnet\sdk\NuGetFallbackFolder' folder.
Here are some options to fix this error:
----------------------------------------
1. Re-run this command with elevated access.
2. Disabled the first run experience by setting the environment variable DOTNET_SKIP_FIRST_TIME_EXPERIENCE to true.
3. Copy the .NET Core SDK to a non-protected location and use it from there.
And this SDK was installed using the MSI? The MSI should expand the cache for you and you should not be getting this message for an MSI installed SDK. Unless, you had DOTNET_SKIP_FIRST_TIME_EXPERIENCE
set to true when you ran the MSI. Which we have actually fixed for our next release.
Yes this was installed via MSI from the .NET download site. I saw this on all of my machines, but the one that it worked, I believe, ran this successfully at first start (because the command prompt was running as admin). This happened to 3 out of 5 machines on my team so definitely feels like some kind of bug.
I was facing the same issue. If anybody is still having the same issue then follow the below steps. Hope it will help you as well.
Thanks
Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.
This issue will now be closed since it has been labeled 'stale' without activity for 30 days.
From @Tadimsky on June 6, 2018 19:7
Details about Problem
I recently updated all of our services to target .NET Core 2.1 and everything worked great on my one machine and on someone else's machine. However, most other people were running into an issue like this:
Nothing seemed to fix it - I tried nuking every nuget cache I could find, reinstalling Visual Studio, etc. I then compared the
project.assets.json
file on the machine that worked with the one that didn't and found that the assets file was not updating properly.This is from the machine that didn't work:
You can see that there are no DLLs listed for
Microsoft.EntityFrameworkCore.Abstractions
and onlynet45
DLLs listed forMicrosoft.IdentityModel.Protocols.OpenIdConnect
.This is on the machine where it worked:
If I delete the
project.assets.json
file on the machine then everything works and it recreates it with the format that works. This seems like a pretty gnarly bug (and took down most of our engineers for the day) - any ideas what's happening? Why wouldnuget restore -force
not blow away this file?NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): Nuget.exe
NuGet version (x.x.x.xxx): 4.6.2.5055
dotnet.exe --version (if appropriate): 2.1.300
VS version (if appropriate): 15.8.0 Preview 2
OS version (i.e. win10 v1607 (14393.321)): 17682.1000
Other suggested things
Verbose Logs
I've attached both of the
project.assets.json
files in this zip: NugetRestore.zipCopied from original issue: NuGet/Home#6999