Enable UsingToolNuGetRepack for exact version dependencies on all inter-package references

[Copilot]

MTP extension packages (TrxReport, CrashDump, Retry, etc.) currently declare >= version dependencies on Microsoft.Testing.Platform. This is problematic with IVT usage — a newer platform version could be resolved at runtime, breaking internal member access.

Setting UsingToolNuGetRepack=true in eng/Versions.props enables Arcade's BuildReleasePackages.targets, which runs UpdatePackageVersionTask with ExactVersions="true" post-pack. This rewrites all inter-package dependency versions to exact ([version]) for both MTP and MSTest packages.

• MTP packages (Microsoft.Testing.*): Get exact version dependencies for inter-package references — critical for IVT safety.

• MSTest packages (MSTest.*): Also get exact version dependencies, including on MTP packages. This ensures version compatibility and avoids issues where updating extensions could bring in an incompatible MTP version.

• PreReleaseVersionLabel is already set (required by the repack tool)

• Arcade SDK version includes BuildReleasePackages.targets with ExactVersions support

• See NuGet/Home#7213 for upstream context

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Youssef1313]

This is very likely going to cause issues for MSTest as it will now require also an exact match of MTP which prevents users from updating even third-party extensions. I'm not sure what's best there to handle this.

[Evangelink]

I was reviewing the created packages, for MTP everything seems to be good. For MSTest, we have the following:

1. MSTest.TestFramework deps on MSTest.Analyzers with =. I think this is ok to have this strong deps because we always optimize for the current version. Given we don't take breaking changes we could ideally have range version (e.g. for framework 4.2, analyzers could be up to v5)

2. MSTest.TestAdapter deps

   • MTP -> it seems perfectly valid
   • MSTest.TestFramework -> despite being a change of behavior, I think this is valid and actually more correct.

@Youssef1313 are there some specific scenario you had/have in mind?

[Youssef1313]

My concern is the MSTest.TestAdapter -> MTP deps. I wouldn't expect it to be a strict equal.

[Evangelink]

@copilot investigate how arcade works https://github.com/dotnet/arcade and try to make it so that MSTest to MTP deps are using either >= or range until the last major version of MTP.

[Copilot]

@copilot investigate how arcade works https://github.com/dotnet/arcade and try to make it so that MSTest to MTP deps are using either >= or range until the last major version of MTP.

I investigated the Arcade SDK's UpdatePackageVersionTask source code (NuGetVersionUpdater.cs). The task only rewrites dependency versions for packages present in the same batch (packages.TryGetValue(id, ...)) — deps on packages outside the batch are left untouched.

The fix in 077350b overrides the PackageReleasePackages target in eng/AfterSolutionBuild.targets to split packages into two separate batches:

• MTP batch (Microsoft.Testing.*): ExactVersions=true → MTP extension → MTP core deps become [version] (exact)
• MSTest batch (MSTest.*): ExactVersions=true but since MTP packages aren't in this batch, MSTest → MTP deps stay as >=. MSTest-internal deps (e.g., TestAdapter → TestFramework) still get exact versions.

This leverages MSBuild's last-definition-wins behavior — since eng/AfterSolutionBuild.targets is imported after BuildReleasePackages.targets in the Arcade SDK's AfterSolutionBuild.proj, our target replaces the original.

[nohwnd]

Personally I've seen the problem many times when updating extensions and those extensions brought version of MTP that was not compatible with my MSTest and no tests were discovered and nothing worked in IDE and there was no error.

IMHO test framework + adapter should depend on each other and should dictate exact version of MTP. Running the tests is the important job here. Users should be able to use older version of the extension, and extensions should use the oldest version of MTP that fits them to avoid forcing new version of MTP that is incompatible with MSTest.

In reality MSTest is shipped on the same cadence as MTP, so if 3rd party extensions get published, there should be already a version of MSTest that relies on the same versions as them.

[Evangelink]

In reality MSTest is shipped on the same cadence as MTP, so if 3rd party extensions get published, there should be already a version of MSTest that relies on the same versions as them.

I agree!

@Youssef1313 Shall we go for a period with the strict restriction and see if people complain before moving to wider range for MSTest to MTP deps?

[Youssef1313]

It's risky IMO, but we can try.

[Evangelink]

It's risky IMO, but we can try.

What risk are you thinking about? Happy to take that offline if you prefer.

[Evangelink]

@copilot please revert to commit 08a9e84

[Copilot]

@copilot please revert to commit 08a9e84

Reverted in 8996451. The split batch workaround in eng/AfterSolutionBuild.targets has been removed — only the UsingToolNuGetRepack=true change in eng/Versions.props from 08a9e84 remains.

[Copilot]

Pull request overview

Enables Arcade’s NuGet repack tooling to rewrite inter-package dependencies to exact versions ([version]), ensuring Microsoft.Testing.Platform (MTP) extension packages and MSTest packages don’t float to newer platform versions that could break IVT-based internal access.

Changes:

• Set UsingToolNuGetRepack=true in eng/Versions.props to turn on exact-version dependency rewriting during packaging.
• Added an inline comment referencing the upstream NuGet issue context.