Explore reducing MSB4011 duplicate-import warnings when MSTest.Sdk is combined with another base SDK

[Evangelink]

Summary

MSTest.Sdk implicitly imports Microsoft.NET.Sdk as its base SDK (both Sdk/Sdk.props.template and Sdk/Sdk.targets do <Import ... Sdk=""Microsoft.NET.Sdk"" />). This means it can't be used as the outer <Project Sdk=""...""> for projects that need a different base SDK such as Microsoft.NET.Sdk.Web (ASP.NET Core integration test projects).

A workaround is to hand-write the SDK imports for both SDKs instead of using the Sdk attribute:

<Project>
  <Import Project=""Sdk.props"" Sdk=""Microsoft.NET.Sdk.Web"" />
  <Import Project=""Sdk.props"" Sdk=""MSTest.Sdk"" />
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>
  <Import Project=""Sdk.targets"" Sdk=""MSTest.Sdk"" />
  <Import Project=""Sdk.targets"" Sdk=""Microsoft.NET.Sdk.Web"" />
</Project>

This functionally works — the project restores, builds, references ASP.NET Core (WebApplication.CreateBuilder()), and runs under the MSTest runner (Passed! Failed: 0, Passed: 2). However, because both MSTest.Sdk and Microsoft.NET.Sdk.Web each import Microsoft.NET.Sdk, the build emits duplicate-import warnings:

warning MSB4011: "...\Microsoft.NET.Sdk\Sdk\Sdk.props" cannot be imported again.
It was already imported at "...\Microsoft.NET.Sdk.Web\Targets\Sdk.Server.props".
This is most likely a build authoring error. This subsequent import will be ignored.

Ask

Explore whether we can make the mixed/manual-import scenario clean, e.g.:

• Guard our base-SDK import with a condition that skips it when Microsoft.NET.Sdk (or a derived SDK such as Microsoft.NET.Sdk.Web) has already been imported (for example, check a well-known property set by the base SDK props), or
• Provide a documented, first-class way to layer MSTest.Sdk on top of a different base SDK without the MSB4011 noise.

Context

Came up while reviewing dotnet/docs#54554, which documents that MSTest.Sdk can't replace a different base SDK and recommends configuring MSTest manually for such projects. It would be nice if combining SDKs were a supported, warning-free path.

[Evangelink]

Additional empirical data: top-level Sdk attribute + manual import of the other SDK

Following up with two more variants (raised by @Youssef1313 in dotnet/docs#54554). These keep one SDK as the top-level Sdk attribute and manually import the other. Tested on net10.0, MSTest.Sdk 3.10.4, with an ASP.NET Core reference and a real [TestMethod].

Variant 1 — top-level Microsoft.NET.Sdk.Web, manually import MSTest.Sdk: builds and tests pass (Passed! Failed: 0, Passed: 2), but emits the same MSB4011 duplicate-import warnings.

Variant 2 — top-level MSTest.Sdk, manually import Microsoft.NET.Sdk.Web: fails to compile, deterministically:

error CS0234: The type or namespace name 'TestingPlatformBuilderHook' does not exist
in the namespace 'Microsoft.VisualStudio.TestTools.UnitTesting'
(obj/.../SelfRegisteredExtensions.cs — generated by the MSTest runner)

plus the same MSB4011 warnings. In this ordering, Microsoft.NET.Sdk.Web''s bottom Sdk.targets (manually imported) runs and the base Microsoft.NET.Sdk targets get imported via Web, so MSTest.Sdk''s own bottom import of the base is skipped (MSB4011), and the runner''s generated SelfRegisteredExtensions bootstrap can''t resolve TestingPlatformBuilderHook.

Summary of all combinations tried:

Layout	Builds?	Tests run?	Warnings
Bare <Project>, manual import of both (MSTest + Web)	✅	✅	MSB4011 ×N
Top Microsoft.NET.Sdk.Web + manual MSTest.Sdk	✅	✅	MSB4011 ×N
Top MSTest.Sdk + manual Microsoft.NET.Sdk.Web	❌ (CS0234)	—	MSB4011 ×N

So a mixed layout can work, but only with MSTest.Sdk layered as the inner import, and even then it''s warning-noisy. Would be great if MSTest.Sdk could (a) guard its base-SDK import to avoid MSB4011 when a derived base SDK is already imported, and (b) make the runner bootstrap robust to import ordering so the reverse layout doesn''t break with TestingPlatformBuilderHook missing.