Home: msbuild /t:Restore and Visual Studio produce different assets files when assembly name != project name

[aolszowka]

Environment(s)

• Visual Studio 2019 16.1.4
• Visual Studio 2017 15.9.13

Issue

See attached project for a small repo of this.

It appears that when you perform an msbuild /restore the project.assets.json that gets generated uses the AssemblyName of the referenced class Library. However if you open up Visual Studio it will perform a restore setting this to the name of the referenced PROJECT file. This change forces a Visual Studio rebuild. It is especially painful depending on the size of the solution.

Repo Project

NuGetProjectAssetsJsonDiffs.zip

1. Starting with a clean project perform a msbuild /restore *.sln
2. Save off the project.asset.json
3. Open the project in Visual Studio, Notice that it will feel the need to restore the project packages again even though in theory it should have already been restored.
4. Compare the "new" project.asset.json to see that it is using the name of the project file as opposed to the assembly name.

[rrelyea]

@nkolev92 @dtivel - known issue?

[nkolev92]

Not as far as I'm aware.

Related code for the fix:
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.PackageManagement.VisualStudio/Projects/LegacyPackageReferenceProject.cs#L332

I'd imagine the references reader is just returning the path.

I'm curious whether this is also an issue with SDK based projects.

[aolszowka]

@nkolev92 We don't use any SDK Based projects at this time. Beyond that, is there something we can do to assist in debugging?

Thank you

[nkolev92]

@aolszowka

Thanks, I think we have everything.

I can repro the bug, and I have verified and it does not repro on SDK based projects, only in the classic csproj projects.

[aolszowka]

We appreciate the transparency of a GitHub bug; is there anything that explains what the various tags mean? "NeedsTriageDiscussion" implies that there will be discussion on where this falls in your priority queue but is that discussion had in a public forum or at certain touch points?

Thank you

[nkolev92]

@aolszowka

This specific tag is usually used to mark that the team internally needs to have a discussion about the risks to determine the priority for scheduling some time for a specific dev to fix it.

Right now we don't have a community stand-up of the sort, but we're always willing to interact with customers on the issues themselves.

We also don't really have a summary of what all our labels mean.

[rrelyea]

Likely broken since VS2015 & project.json and since VS 2017 & packageref. As such, good bug to fix, but first complaint, we think.

[aolszowka]

@rrelyea Its a particularly subtle bug, I suspect most devs would write it off as happenstance because after the "second build" in Visual Studio it goes away. We only notice it due to the scale of of our product (~1500 C# Files which FORCE us to build via MSBuild THEN open in VS otherwise we OOM Everywhere when trying to build).

On rebuilds it disappears but we also have a number of versions (~9 active versions at any given time) which causes the rebuild from scratch to happen much more often than one would think. Our deep dependency tree has hurt us as well.