VS stuck in a nuget restore loop

[epananth]

• [ ] This issue is blocking
• [ ] This issue is causing unreasonable pain

Adam Boniecki reported a problem through VS: FeedbackTicket 2607996 VS stuck in a nuget restore loop

The root cause is that the Arcade SDK is adding a PackageReference using the above property name as the package version: https://github.com/dotnet/arcade/blob/44fcbaed452f475cf7d781c61cbfeca4de455dcc/src/Microsoft.DotNet.Arcade.Sdk/tools/VisualStudio.targets#L28

But the package itself is redefining the same property name to a different value: https://dev.azure.com/devdiv/DevDiv/_git/VSExtensibility?path=/src/nuget/extensibility/Microsoft.VSSDK.BuildTools/Microsoft.VSSDK.BuildTools.csproj&version=GBdevelop&line=477&lineEnd=478&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents

Due to design and performance decisions, this version overwriting causes NuGet restores to go in a loop. I think either the property name that Arcade uses needs to change, or work with the VS extensibility team to get them to change the property name they use in the package. Looking at the git diff, it looks like they started doing it only last year.

But right now there's a property name conflict causing the VS restore loop problem, and it'll probably affect all repos using Arcade and a VSSDK BuildTools package above a certain version number.

[epananth]

cc : @zivkan

[akoeplinger]

the easiest fix would be to switch to the MicrosoftVSSDKBuildToolsPackageVersion property name in arcade (we define both suffixes)

[abonie]

@akoeplinger what you mentioned above is a fix on arcade's side I assume? Because replacing references to MicrosoftVSSDKBuildToolsVersion with MicrosoftVSSDKBuildToolsPackageVersion on our side doesn't seem to affect this issue

[zivkan]

I think he was suggesting it as proposed change to Arcade, that would need to flow to the F# repo once merged. They'd need to change the property name on the PackageReference I linked to when I reported the problem. See the version attribute on the original post in this issue.

I'd suggest that Arcade also adds an explicit opt-out property. As someone on the NuGet team, when a customer experiences a problem like this, I'd normally suggest customers to stop using custom build scripts. But Arcade gates this on the GeneratePkgDefFile property, which the VSSDK BuiltTools itself uses and therefore can't be set to false: https://github.com/dotnet/arcade/blob/44fcbaed452f475cf7d781c61cbfeca4de455dcc/src/Microsoft.DotNet.Arcade.Sdk/tools/VisualStudio.targets#L27-L28

If Arcade SDK users could opt out of this automatic PackageReference, then they could add their own PackageReference as a workaround.

Another possible workaround is to use a Directory.Build.Targtes and do

<PackageReference Update="Microsoft.VSSDK.BuildTools" Version="1.2.3" />

Change 1.2.3 to whatever version of the package you want to use. This will stop Arcade from using the version property that the package overwrites to a higher version every restore, and will make restore deterministic.

[abonie]

Thanks @zivkan , this has worked and since we had external contributors complaining about working with our sln I merged this temporary fix https://github.com/dotnet/fsharp/pull/19106, but it would great to see a fix on Arcade's side