Different restore behavior in IDE / command line for PrivateAssets

[jaredpar]

NuGet Version Used: VS 15.5.2 && VS 15.3.5

I'm seeing a restore behavior difference for a package reference marked as <PrivateAssets>all</PrivateAssets> between the IDE and command line. The intent here is to keep the reference and all its assets from flowing into the projects that reference it.

In the command line scenario, driven by msbuild.exe, the scenario behaves as expected. The PackageReference is completely absent from the project.assets.json file of the referencing project. In the IDE scenario though the PrivateAssets is not respected, the PackageReference ends up in the referencing project and the build fails.

Here is the structure of the PackageReference I'm using:

<PackageReference Include="FSharp.Core" Version="4.0.0.1">
  <PrivateAssets>all</PrivateAssets>
</PackageReference>

Detailed repro instructions below. Note that in order to run the repro below you will need to have the F# workload installed into Visual Studio.

• Clone the VsVim project
• Switch to branch repro/nuget-ide-restore
• Run msbuild /v:m /m /t:Restore VsVim.sln. At this point you can examine the project.assets.json file from Binaries\obj\VimWpf\project.assets.json and notice that the FSharp.Core reference is missing (as is expected).
• Run msbuild /v:m /m VsVim.sln and notice the build succeeds

Now to see the bug repro do the following

• Run git clean -dxf .
• Open VsVim.sln in Visual Studio. Make sure that automatic package restore is enabled
• Build the VimWpf project and notice the build errors. The text of the error will mention ambiguous reference to types like FSharp.Option
• At this point you can examine the project.assets.json file from Binaries\obj\VimWpf\project.assets.json and notice that the FSharp.Core reference is present. This is not expected.

[jaredpar]

This is still a problem in 15.6

[jaredpar]

Is there any ETA for this issue? This makes it very difficult for developers to contribute to my project. In order to edit my solution they must:

1. Disable VS ability to do NuGet restore (since IDE restore is broken)
2. Restore on the commandline

Step 2 must be repeated every time that a change is made to the project file. Whenever a developer forgets to do this they encounter all manner of build errors in the IDE.

[jainaashish]

Restoring in VS worked fine for me, it didn't have Fsharp.Core refeerence in Binaries\obj\VimWpf\project.assets.json

I don't think it will matter but I tried with latest VS 15.7.1

[jaredpar]

@jainaashish the initial restore will often work. Once you edit slightly and rebuild then the restore which occurs as a part of build will fail. The repro is a bit intermittent but it does show up. I can provide logs if that helps.

[jaredpar]

@jainaashish I tested out on 15.7 and I'm immediately stuck by a different bug (or at least restore behavior change). Now I get the following:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warnin g MSB3243: No way to resolve conflict between "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" an d "System.ValueTuple, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51". Choosing "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" arbitrarily. [E:\code\VsVim\Test\VimWpfTest\VimWpfTest.csproj]

This is a new behavior with 15.7. It will repro on command line and IDE. Same code works just fine in 15.6. Joyful. Need to track this down before I can get back to reproducing the original bug.

Even if it doesn't reproduce though I don't really feel that is sufficient. There was no action taken here, and no visible understanding of what was wrong. How can we be confident this won't happen again?

[jaredpar]

@jainaashish the description in the linked AppVeyor bug has another repro of this issue. Copied here for simplicity:

• Clone https://github.com/jaredpar/VsVim
• git reset --hard 7f3a6fd0cf5aa4e79cf2b6d8f1e03ac3f2c66d50
• nuget restore VsVim.sln
• msbuild /v:m /m VsVim.sln

When using NuGet 4.3.0 you will hit this bug. I'm not sure on which other builds this bug will occur (does not occur in 4.6.2). But the behavior is easy to see.

[jainaashish]

@jaredpar I'm lil confused as where this bug exactly repro's? so let me summarize what I understood and correct me if I'm wrong:

1. MSBuild /t:restore - always works fine.
2. NuGet.exe restore - 4.3.0 has some issues but latest version is working fine.
3. VS - Initial restore works fine, but some intermittent issues with subsequent build restores.

So, I'll look into this VS specific issue and see, if I can repro it locally and investigate.

[jainaashish]

@jaredpar I saw the issue with NuGet.exe 4.3.0 but couldn't repro with latest version so assuming it was fixed some where post 4.3.0.

But I'm still not able to repro it even once in VS with 15.7 release so can you please share the detailed logs when you see this issue and clear repro steps to repro inside VS?

[jaredpar]

I saw the issue with NuGet.exe 4.3.0 but couldn't repro with latest version so assuming it was fixed some where post 4.3.0.

I see the same. I think this is the repro to focus on. It happens every time and it is the original repro that I was seeing.

But I'm still not able to repro it even once in VS with 15.7 release so can you please share the detailed logs when you see this issue and clear repro steps to repro inside VS?

I'm unable to reproduce it in the IDE due to #6936. That blocks IDE work on the setup where the bug occurs.

[jainaashish]

I see the same. I think this is the repro to focus on. It happens every time and it is the original repro that I was seeing.

I don't think this is the repro to focus on, since this doesn't repro with latest nuget.exe and in most cases, it's the same code which runs across VS or NuGet.exe. So I'd imagine this will just work fine with VS as well even after #6936. So once that issue is resolved, then we can look again at this.

[jaredpar]

So once that issue is resolved, then we can look again at this.

This bug investigation keeps getting delayed. The repro I've provided now both:

1. Reproduces 100% of the time
2. Eliminates targets changes to C# / F# from being part of the problem

Not sure why this would be delayed at this point. There is a clear behavior change from 4.3.0 to 4.6.0 that has no explanation. If the decision is to delay now I'm unsure when there would ever be a good time to look at this bug.

If the bug is fixed that's great. But given the behavior change wasn't identified it seems probable it could regress again.

[jaredpar]

This has come up yet again with VS 15.8 Preview 4. Once again I'm completely unable to develop my project because of this restore.

EDIT

Bug also rerpoduces on Preview 5

[jaredpar]

Can we please remove the "NeedsRepro" tag from this issue? There have been several clear repros given that the team has acknowledged in the past. Continuing to keep this label makes the issue look misleading unless you read the thread.

[jaredpar]

Note: with 15.8 Preview 4 the bug will reproduce from the command line. I have not checked the IDE. Simple repro:

1. Clone https://github.com/jaredpar/VsVim
2. Run msbuild /v:m /m /t:restore VsVim.sln
3. Run msbuild /v:m /m VsVim.sln

There will be lots of errors around types that exist in FSharp.Core and Vim.Core.

[onyxmaster]

VS16.5.5 still has this problem for us, breaking build.

[nkolev92]

Dup of #9864.

tldr; when duplicates includes of PackageReference items exist, commandline picks first, VS picks second.
a

I understand the other issue is newer, but it contains more engagement.

I have confirmed that my suspicion is correct by putting a .Reverse() on this line: https://github.com/NuGet/NuGet.Client/blob/a4c9d63bf942f1df1ba9486a87bad2e4b6888488/src/NuGet.Core/NuGet.Build.Tasks/GetRestorePackageReferencesTask.cs#L45 and running latest restore.
When I did that, the build succeeded.