Skip to content

Conversation

@Youssef1313
Copy link
Member

No description provided.

@Youssef1313 Youssef1313 marked this pull request as ready for review January 2, 2026 09:33
</ItemGroup>
<ItemGroup>
<!-- Microsoft.NET.Test.Sdk breaks netcoreapp2.0 -->
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.14.1" Condition=" '$(TargetFramework)' != 'netcoreapp2.0' " />
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excluding Microsoft.NET.Test.Sdk on netcoreapp2.0 likely meant that the tests never executed for netcoreapp2.0.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never had any problems running the tests in VS (we don't run these in CI so it doesn't matter there).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And do the netcoreapp2.0 tests specifically run correctly?
I haven't tried but I doubt. Without this package reference, there is no testhost to run the tests.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you doubt?

image

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The testhost.exe is supposed to come through Microsoft.NET.Test.Sdk. So, without this package, there is no testhost.exe.

However, for this specific case, it looks like Microsoft.NET.Test.Sdk is still brought via xunit.runner.visualstudio 2.4.1. But that's no longer the case for newer xunit.runner.visualstudio packages that don't declare Microsoft.NET.Test.Sdk as a dependency.

In addition, version 15.0.0 of Microsoft.NET.Test.Sdk which is brought by xunit.runner.visualstudio 2.4.1 is also extremely old.

I personally think it's a lot of hassle with low value. A tfm is out of support for a reason. It's not supported, hence it's not worth testing against, especially when it comes with many drawbacks like forcing old dependencies, forcing suppressing warnings (including NuGet security warnings), and preventing moving forward (e.g, migrating from VSTest to Microsoft.Testing.Platform). IMHO, these are big enough drawbacks compared to the value of "manually testing out of support TFMs".

Copy link
Collaborator

@timcassell timcassell Jan 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we want to update our testing framework, we can update the TFMs if it's necessary for the update. I don't see the point of updating the TFMs by themselves. The ManualRunning.MultipleFrameworks project is small enough for someone to experiment with newer XUnit or TUnit before doing it for the entire repo.

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.14.1" />
<PackageReference Include="xunit" Version="2.9.3" />
<!-- We use older version 2.4.1 for combatibility with netcoreapp2.0. -->
<!-- We use older version 2.4.1 for combatibility with net461 -->
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably you can consider updating the tests from net461 to net462.

@timcassell
Copy link
Collaborator

timcassell commented Jan 2, 2026

I still don't understand the need for this. I can run the tests without issue in VS 2026 and 2022.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants