Drop Microsoft.NET.Test.Sdk from the MSTest metapackage#9546
Draft
nohwnd wants to merge 1 commit into
Draft
Conversation
MSTest runs as a Microsoft.Testing.Platform app, so it doesn't need the classic VSTest runner. Referencing Microsoft.NET.Test.Sdk dragged in Microsoft.TestPlatform.TestHost and the rest of the VSTest execution stack. Removing it leaves Microsoft.TestPlatform.ObjectModel as the only VSTest-lineage package the MSTest package brings in - it flows transitively through the VSTestBridge (alongside the source-only, non-flowing Filter.Source). Build integration still comes from Microsoft.Testing.Platform.MSBuild via MSTest.TestAdapter. Verified against the restore graph (net462;net8.0;net9.0;uap10.0) and a real packed nuspec: no Test.Sdk, no TestHost, ObjectModel only. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the MSTest meta-package to stop referencing Microsoft.NET.Test.Sdk, aiming to reduce MSTest’s transitive dependency on the classic VSTest execution stack and rely on Microsoft.Testing.Platform (MTP) components instead.
Changes:
- Removed the
PackageReferencetoMicrosoft.NET.Test.Sdkfrom the MSTest meta-package. - Replaced prior rationale comments with a new explanation describing the intentional omission and the remaining VSTest-lineage dependency flow.
Comment on lines
+52
to
60
| <!-- | ||
| Microsoft.NET.Test.Sdk (the classic VSTest runner, which drags in Microsoft.TestPlatform.TestHost and the | ||
| rest of the VSTest execution stack) is intentionally NOT referenced. MSTest runs as a | ||
| Microsoft.Testing.Platform (MTP) application and does not need the VSTest testhost/runner. Dropping it keeps | ||
| the MSTest package's only VSTest-lineage dependency down to Microsoft.TestPlatform.ObjectModel, which flows | ||
| transitively through Microsoft.Testing.Extensions.VSTestBridge (plus the source-only, non-flowing | ||
| Microsoft.TestPlatform.Filter.Source). MTP build integration is provided by Microsoft.Testing.Platform.MSBuild | ||
| (flowed via MSTest.TestAdapter), not by Microsoft.NET.Test.Sdk. --> | ||
| <PackageReference Include="Microsoft.Testing.Extensions.CodeCoverage" /> |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft / illustrative — companion to microsoft/vstest#16201. Not meant to merge as-is.
MSTest already runs as a Microsoft.Testing.Platform (MTP) app, so it doesn't need the classic VSTest runner. The
Microsoft.NET.Test.Sdkreference in the MSTest metapackage drags inMicrosoft.TestPlatform.TestHostand the rest of the VSTest execution stack. Dropping it leavesMicrosoft.TestPlatform.ObjectModelas the only VSTest-lineage package MSTest brings in — and that flows transitively throughMicrosoft.Testing.Extensions.VSTestBridge(alongside the source-only, non-flowingMicrosoft.TestPlatform.Filter.Source). Build integration still comes fromMicrosoft.Testing.Platform.MSBuildviaMSTest.TestAdapter.Why bother: on the vstest side I taught
vstest.console/datacollectorto run pure-MTP apps directly over the MTP protocol — including in a single mixed run next to a classic vstest-based project, with TRX + coverage. This testfx draft is the other half of that picture: proof that MSTest could shed its vstest deps and still be driven by vstest in a mixed run. You don't need to do both — the point is that the migration can be incremental. Port some tests to MTP, then all of them, then move the infra (reporting, CI) off vstest when it's convenient — instead of replacing test infra, reporting, and every test in one shot. And no dynamic code loading.Known limitation (coverage). The vstest "Code Coverage" datacollector binaries ship in
Microsoft.CodeCoverageand normally reach vstest.console throughMicrosoft.NET.Test.Sdk(Microsoft.CodeCoverage.propssetsTraceDataCollectorDirectoryPath, which the SDK's VSTest task forwards asVSTestTraceDataCollectorDirectoryPath). A metapackage without Test.Sdk won't restore those DLLs, so vstest-datacollector coverage on such a project needs another source for them — the project referencesMicrosoft.CodeCoverage, or vstest bundles the collector in its runner. Pinned for a design discussion with the owner of code coverage. MTP-native coverage is unaffected: the metapackage still referencesMicrosoft.Testing.Extensions.CodeCoverage.Verified on the base it was authored against — restore graph
net462;net8.0;net9.0;uap10.0plus a real packed nuspec: no Test.Sdk, no TestHost, ObjectModel only. The metapackage region is unchanged onmain, so it cherry-picks clean.Co-authored with GitHub Copilot.