Avoid setting IsTestingPlatformApplication in MTP.targets

[Youssef1313]

See discussion in #7557

In short, we should leave this up to test frameworks.

• This shouldn't be a big change for MSTest/NUnit in most common/normal cases.
• It's also not a big change for TUnit as it explicitly sets IsTestingPlatformApplication to true anyways.
• It might be a problem for xunit.v3, but I don't know if we should still take this change as it makes more sense IMO. IMPORTANT TO DISCUSS BEFORE MERGE

[Copilot]

Pull request overview

This change updates the MSBuild integration for Microsoft.Testing.Platform by removing the default assignment of the IsTestingPlatformApplication property from the platform’s .targets file.

Changes:

• Removed the conditional default (true when unset) for IsTestingPlatformApplication from Microsoft.Testing.Platform.targets.

---

You can also share your feedback on Copilot code review. Take the survey.

[Youssef1313]

Ping @bradwilson. This is technically a breaking change that's expected to have only an impact for xunit.v3 which doesn't have a "gated" property for choosing between VSTest/MTP. If this is merged, what will happen if you want to preserve the current behavior is:

• Next version of xunit.v3 will need to explicitly set <IsTestingPlatformApplication>true</IsTestingPlatformApplication> in package props/targets.
• Existing xunit.v3 versions will not preserve the original behavior whenever users update to latest MTP, and users will then need to also update xunit.v3 along with MTP.

If nothing is done, then the most likely visible impact will be for .NET 10 SDK users using the MTP-based test command, which will now not recognize xunit.v3 test projects as MTP.

[Youssef1313]

We will need to update MTP integration tests here, but I'm deferring that until we decide whether we will move forward with the change.

[bradwilson]

Since this is a breaking change, are you major version bumping? It's an easier story to tell people who break themselves with a major version upgrade than a minor.

[Evangelink]

Since this is a breaking change, are you major version bumping? It's an easier story to tell people who break themselves with a major version upgrade than a minor.

That's the main reason for explicitly asking you upfront :) As you know, having close major bumps is not liked much around here. It's also a particular problem as you generate new package names for every new version of MTP (it actually should not be but you know people).

We were trying to see if there would be something from xUnit we could use to preserve the mode for you but we haven't really found anything relevant.

[bradwilson]

We were trying to see if there would be something from xUnit we could use to preserve the mode for you but we haven't really found anything relevant.

There are no MSBuild properties for you to hang this off that I can think of. Everything we have is optional.

[Youssef1313]

And how big deal the breaking change will be for you?

Maybe to reduce the impact, you can start adding <IsTestingPlatformApplication>true</IsTestingPlatformApplication> explicitly in xunit props/targets in the next version, and we postpone the breaking change after majority of your users are already on a version that won't notice the break here?

[bradwilson]

And how big deal the breaking change will be for you?

If MTP suddenly stops working with no reasoning why? That seems pretty big.

Maybe to reduce the impact, you can start adding true explicitly in xunit props/targets in the next version

Sure, that's no problem.

we postpone the breaking change after majority of your users are already on a version that won't notice the break here?

I honestly have no way of determining this, other than trying to watch and interpret changes in download counts, something I do not do now (nor have any tools for automating at the moment).

[bradwilson]

An additional factor I have no insight into is how many people choose to include a newer version of MTP vs. the number of people who get what comes in-box by default.

[Evangelink]

@bradwilson I will see if we have some more precise info from our telemetry or nuget telemetry, if so I'll ask what I can share with you (by email if that's ok).

[bradwilson]

Maybe to reduce the impact, you can start adding true explicitly in xunit props/targets in the next version

Is this just for MTP, or also for VSTest? (by name, it seems MTP specific, but just wanted to validate)

[bradwilson]

Yes?

diff --git a/src/xunit.v3.core/Package/buildTransitive/xunit.v3.core.props b/src/xunit.v3.core/Package/buildTransitive/xunit.v3.core.props
index 113d405a..fd926d4c 100644
--- a/src/xunit.v3.core/Package/buildTransitive/xunit.v3.core.props
+++ b/src/xunit.v3.core/Package/buildTransitive/xunit.v3.core.props
@@ -8,6 +8,8 @@
     <GenerateSelfRegisteredExtensions>true</GenerateSelfRegisteredExtensions>
     <!-- Turn off Microsoft.Testing.Platform.MSBuild's auto-generated entrypoint -->
     <GenerateTestingPlatformEntryPoint>false</GenerateTestingPlatformEntryPoint>
+    <!-- Enable 'dotnet test' support for Microsoft.Testing.Platform -->
+    <IsTestingPlatformApplication Condition=" '$(IsTestingPlatformApplication)' == '' ">true</IsTestingPlatformApplication>
     <TestProject>true</TestProject>
     <!-- Force the app host for .NET builds, since it's required for xunit.v3.runner.utility to run v3 projects -->
     <UseAppHost>true</UseAppHost>

[bradwilson]

Out of curiosity, doesn't you moving <IsTestingPlatformApplication> setting from Microsoft.Testing.Platform to Microsoft.Testing.Platform.MSBuild solve the problem? Shouldn't the latter package only be used by test projects and not extensibility projects?

Edit: It looks like maybe you moved it in 1.6.3, as it used to be in Microsoft.Testing.Platform.MSBuild. If this was due to dependencies, what about moving the set to the Microsoft.Testing.Platform.MSBuild.props file, since it appears all the consumption is in Microsoft.Testing.Platform.targets?