Fix VS NuGet restore loop caused by VSSDK property name conflict

[Copilot]

Microsoft.VSSDK.BuildTools redefines the MicrosoftVSSDKBuildToolsVersion property to a different value in its own build logic. Since Arcade uses that same property name for the PackageReference version, NuGet sees the version change after every restore and loops indefinitely.

Changes

• Rename property MicrosoftVSSDKBuildToolsVersion → MicrosoftVSSDKBuildToolsDefaultVersion in DefaultVersions.props to break the conflict
• Add opt-out IncludeMicrosoftVSSDKBuildToolsPackageReference property in VisualStudio.targets so repos can manage the reference themselves
• Bump version 16.9.1050 → 17.14.2120

<!-- Opt out of the automatic PackageReference if needed -->
<PropertyGroup>
  <IncludeMicrosoftVSSDKBuildToolsPackageReference>false</IncludeMicrosoftVSSDKBuildToolsPackageReference>
</PropertyGroup>

To double check:

• The right tests are in and the right validation has happened. Guidance: https://github.com/dotnet/arcade/blob/main/Documentation/Validation.md

Original prompt

---

This section details on the original issue you should resolve

<issue_title>VS stuck in a nuget restore loop</issue_title>
<issue_description>

• 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:

arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/VisualStudio.targets

Line 28 in 44fcbae

<PackageReference Include="Microsoft.VSSDK.BuildTools" Version="$(MicrosoftVSSDKBuildToolsVersion)" PrivateAssets="all" IsImplicitlyDefined="true" />

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.</issue_description>

Comments on the Issue (you are @copilot in this section)

@epananth cc : @zivkan @akoeplinger the easiest fix would be to switch to the MicrosoftVSSDKBuildTools**Package**Version 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:

arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/VisualStudio.targets

Lines 27 to 28 in 44fcbae

	<ItemGroup Condition="'$(IsVsixProject)' == 'true' or '$(GeneratePkgDefFile)' == 'true'">
	<PackageReference Include="Microsoft.VSSDK.BuildTools" Version="$(MicrosoftVSSDKBuildToolsVersion)" PrivateAssets="all" IsImplicitlyDefined="true" />

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.</comment_new>
<comment_new>@abonie
Thanks @zivkan , this has worked and since we had external contributors complaining about working with our sln I merged this temporary fix dotnet/fsharp#19106, but it would great to see a fix on Arcade's side</comment_new>
<comment_new>@akoeplinger
Yeah let's:

• rename the property name in arcade's DefaultVersions.props from MicrosoftVSSDKBuildToolsVersion to MicrosoftVSSDKBuildToolsDefaultVersion and add a comment mentioning the naming conflict
• add an opt out property IncludeMicrosoftVSSDKBuildToolsPackageReference
• update to the latest version 17.14.2120 of the package</comment_new>

• Fixes VS stuck in a nuget restore loop #16228

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.