Add cross-platform netstandard2.0 test coverage

[Copilot]

Summary

On non-Windows platforms, the net8.0 test target now uses the netstandard2.0 build of ModelContextProtocol.Core to provide cross-platform netstandard2.0 test coverage.

Changes

Modified: tests/ModelContextProtocol.Tests/ModelContextProtocol.Tests.csproj

• Added conditional SetTargetFramework on the ModelContextProtocol.Core project reference
• Applied only when TargetFramework is net8.0 AND platform is not Windows

Implementation

<ProjectReference Include="..\..\src\ModelContextProtocol.Core\ModelContextProtocol.Core.csproj">
  <!-- On non-Windows platforms, force net8.0 tests to use netstandard2.0 build for cross-platform netstandard2.0 coverage -->
  <SetTargetFramework Condition="'$(TargetFramework)' == 'net8.0' AND !$([MSBuild]::IsOSPlatform('Windows'))">TargetFramework=netstandard2.0</SetTargetFramework>
</ProjectReference>

Behavior

Windows

• Test targets: net10.0, net9.0, net8.0, net472
• net472: Tests netstandard2.0 on .NET Framework
• net8.0: Uses net8.0 build (no change from before)
• Other targets: Use matching TFMs

Non-Windows (Linux/macOS)

• Test targets: net10.0, net9.0, net8.0
• net8.0: Uses netstandard2.0 build (NEW - provides netstandard2.0 test coverage)
• Other targets: Use matching TFMs

Result

• Netstandard2.0 builds are now tested on all platforms
• Windows: via net472 on .NET Framework
• Non-Windows: via net8.0 runtime with netstandard2.0 assets

Original prompt

Background

As discussed in PR #1226, the current approach of only running net472 tests on Windows creates a gap: developers on non-Windows platforms cannot test the netstandard2.0 build of the product code locally. While mono can be used to run net472 tests, it has reliability issues and isn't a real-world scenario we care about validating.

Suggested Solution

Following the pattern used by googleapis/dotnet-genai, create a new test project that:

1. Targets a modern .NET TFM (e.g., net8.0) - runs on all platforms without mono
2. Forces the project reference to use netstandard2.0 using <SetTargetFramework>TargetFramework=netstandard2.0</SetTargetFramework> on the ProjectReference
3. Includes the same test source files from the main test project

Implementation Details

Create a new test project tests/ModelContextProtocol.Netstandard2_0.Tests/ModelContextProtocol.Netstandard2_0.Tests.csproj that:

1. Targets net8.0 only (stable TFM that works cross-platform)
2. References ModelContextProtocol.Core with <SetTargetFramework>TargetFramework=netstandard2.0</SetTargetFramework>
3. Similarly references any other product projects that have netstandard2.0 targets
4. Includes the test source files from ModelContextProtocol.Tests using <Compile Include> patterns (similar to how the dotnet-genai project does it)
5. References all the same test dependencies (xunit, Moq, etc.)

The key MSBuild pattern from the reference project:

<ProjectReference Include="..\..\src\ModelContextProtocol.Core\ModelContextProtocol.Core.csproj">
  <SetTargetFramework>TargetFramework=netstandard2.0</SetTargetFramework>
</ProjectReference>

This allows testing the netstandard2.0 build of the product on any platform using modern .NET runtime, without requiring mono.

Files to Create/Modify

1. Create tests/ModelContextProtocol.Netstandard2_0.Tests/ModelContextProtocol.Netstandard2_0.Tests.csproj - new test project
2. Potentially update the solution file to include the new project
3. Ensure the new project is discovered by the test infrastructure

Reference

See the discussion at the end of #1226 for context, particularly the comment linking to: https://github.com/googleapis/dotnet-genai/blob/f0d9a3eb970e91293b806dac49853b68e4ddcdca/Google.GenAI.Tests/Netstandard2_0Tests/Google.GenAI.Netstandard2_0.Tests.csproj#L23

This pull request was created from Copilot chat.

---

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

[eiriktsarpalis]

@copilot Please avoid using a separate test project. Ideally this should use the exact same test project, but non-Windows environments should be configured automatically accordingly.

[Copilot]

Changed to use the existing test project with conditional SetTargetFramework on the ModelContextProtocol.Core project reference. On non-Windows platforms, net8.0 tests now use the netstandard2.0 build automatically. See commit 753cc88.

[eiriktsarpalis]

@copilot you probably also need to remove DefaultTestTargetFrameworks which is used by the earlier attempt to fix this same issue.

[Copilot]

Removed the platform-specific conditional logic from DefaultTestTargetFrameworks and made SetTargetFramework apply to all platforms. All platforms now test the same target frameworks (net10.0, net9.0, net8.0) with net8.0 using netstandard2.0 builds everywhere. See commit db11c07.

[eiriktsarpalis]

@copilot ideally we would want a way to still verify the net482 tests build in non windows platforms. We should either keep the target while ensuring tests aren't being run at all, or perhaps add a non-Windows specific netstandard2.0 target acting as a proxy for net482.

[Copilot]

@copilot ideally we would want a way to still verify the net482 tests build in non windows platforms. We should either keep the target while ensuring tests aren't being run at all, or perhaps add a no...

I attempted to add netstandard2.0 as a proxy target on non-Windows, but encountered package compatibility issues - the test packages (xunit, Microsoft.Extensions.TimeProvider.Testing) don't support netstandard2.0, causing NU1701 errors that can't be suppressed during restore.

Would you prefer:

1. Adding net472 to all platforms (if .NET Framework reference assemblies are available on non-Windows)
2. A different approach to verify net472 builds without actually adding it as a target framework?

[eiriktsarpalis]

Adding net472 to all platforms (if .NET Framework reference assemblies are available on non-Windows)

@copilot This would default to having the tests run using mono, which is something we want to avoid.

[eiriktsarpalis]

@copilot

[Copilot]

Adding net472 to all platforms (if .NET Framework reference assemblies are available on non-Windows)

@copilot This would default to having the tests run using mono, which is something we want to ...

Understood. Given that:

• Adding net472 to non-Windows would use mono (undesirable)
• netstandard2.0 as a proxy target has package compatibility issues

The current solution maintains the original goal: providing netstandard2.0 test coverage on non-Windows via net8.0 with SetTargetFramework, while Windows continues to test both net472 (for .NET Framework) and the modern TFMs. The net472 build verification on non-Windows appears infeasible without mono or additional tooling.

[eiriktsarpalis]

@copilot what are the package compatibility issues with netstandard?

[Copilot]

@copilot what are the package compatibility issues with netstandard?

When I attempted to add netstandard2.0 as a test target, the following test packages caused NU1701 errors during NuGet restore:

• Microsoft.Extensions.TimeProvider.Testing 10.1.0
• xunit.v3 3.2.2
• xunit.runner.visualstudio 3.1.5
• xunit.v3.mtp-v1 3.2.2
• xunit.v3.runner.inproc.console 3.2.2

These packages were restored using .NET Framework targets instead of netstandard2.0, causing NU1701 warnings that became errors due to TreatWarningsAsErrors=true in Directory.Build.props. The warnings couldn't be suppressed because they occur during restore, before target framework-specific properties are evaluated. Additionally, making the test project target netstandard2.0 requires changing OutputType from Exe to Library, which means it wouldn't run tests—only verify compilation.

[eiriktsarpalis]

Additionally, making the test project target netstandard2.0 requires changing OutputType from Exe to Library, which means it wouldn't run tests—only verify compilation.

@copilot yes that is expected and desirable.

[Copilot]

Additionally, making the test project target netstandard2.0 requires changing OutputType from Exe to Library, which means it wouldn't run tests—only verify compilation.

@copilot yes that is exp...

I attempted to implement netstandard2.0 as a build-only target (Library), but encountered fundamental issues:

1. xUnit requires Exe: xUnit.net v3 explicitly requires OutputType=Exe and fails with an error when building as Library
2. NuGet restore NU1701 warnings: Package compatibility warnings from restore cannot be suppressed (occur before TFM-specific properties are evaluated)
3. Microsoft.NET.Test.Sdk unsupported: The test SDK doesn't support netstandard2.0 and requires SuppressTfmSupportBuildErrors=true

Even with all suppressions, xUnit's hard requirement for Exe makes the Library approach non-viable for a test project using xUnit. Would a separate, minimal test project targeting netstandard2.0 without xUnit dependencies work instead?

[eiriktsarpalis]

@stephentoub are you ok with net8.0 silently using the ns2.0 build in non-Windows platforms?

[eiriktsarpalis]

@copilot please update the PR title and description to accurately reflect what is being changed.

[Copilot]

@copilot please update the PR title and description to accurately reflect what is being changed.

Updated the PR title and description to accurately reflect the single file change: adding conditional SetTargetFramework to the ModelContextProtocol.Core project reference in the test project, which applies only to net8.0 on non-Windows platforms.

[stephentoub]

@stephentoub are you ok with net8.0 silently using the ns2.0 build in non-Windows platforms?

My preference would be a separate .csproj as outlined at #1235 (comment) so that it's very clear, but I don't feel super strongly about it. @halter73 ?