Rename Package MsTest.Sdk to Microsoft.NET.Sdk.Test

[Varorbc]

Summary

https://www.nuget.org/packages/MSTest.Sdk

Microsoft provides most of the package name is the full name, I hope the package name is also the full name, so that users feel is a system, Not an alternative.Just like the following names

Microsoft.NET.Sdk
Microsoft.NET.Sdk.Web
Microsoft.NET.Sdk.Worker
Microsoft.NET.Sdk.BlazorWebAssembly

Background and Motivation

Proposed Feature

Alternative Designs

[MarcoRossignoli]

I think there's some confusion around the concept of MSBuild SDK, MSTest.Sdk and dotnet SDK (dotnet build etc...)

MSBuild SDK: This is an MSBuild feature that let you ship an MSBuild(targets/props) as custom MSBuild sdk like explained here https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk?view=vs-2022
MSTest.Sdk: is what we shipped here https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-mstest-sdk so it's the MSTest custom MSBuild sdk.
dotnet SDKs: some MSBuild sdks are shipped inside the official dotnet SDK and are documented here https://learn.microsoft.com/en-us/dotnet/core/project-sdk/overview

So use a generic full name Microsoft.NET.Sdk.Testing is confusing because

• every different test adapter has got different versioning and different set of packages. What if you want to use xUnit or nUnit or something else? The sdk name is too generic.
• the MSTest.Sdk is not inserted inside the sdk but it's resolved through nuget and so doesn't work like the other "inserted" MSBuild sdk but you have always to specify the version inside the csproj or global.json.

[Nirmal4G]

comment from dotnet/sdk#25797 (comment)

I thought Microsoft was good at naming. You guys disappoint me. You have loads of names at your disposal. Come on! Pick a good one that is simple and is a one word change to the standard SDK Name.

Some Examples:

• Microsoft.Test.Sdk
• Microsoft.Testing.Sdk
• Microsoft.NET.Test.Sdk
• Microsoft.NET.Sdk.Test
• Microsoft.NET.Sdk.Testing
• Microsoft.NET.Testing.Sdk

Pick one from above that seems intuitive to users who are already familiar with existing packages. Please do note that Microsoft.NET.Test.Sdk package can only be used as a package reference. So, why not convert to an SDK, ship in-band with the .NET SDK and deprecate the package reference functionality after v18?

[MarcoRossignoli]

@Nirmal4G thanks for the suggestion, here I've explained because at the moment use some of that names could be problematic for future evolution #2693 (comment)

I think that MSBuild SDK for testing make sense if at the end the usage allows an "empty" csproj like https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-mstest-sdk otherwise simply move 1 reference from the user project file to the sdk won't help a lot with the transparent evolution of testing frameworks.

[martincostello]

As it stands, the suggestions in this comment #2693 (comment) don't seem to make it specific that the SDK is specifically for MSTest. From the blog posts so far, it doesn't seem like the new test SDK is intended to support NUnit, xunit etc. as they aren't neccessarily compatible with things like native AoT.

[Evangelink]

I think it would only makes sense to reword the MSTest.Sdk package under one of the following conditions:

• we start to integrate MSTest SDK into .NET SDK
• we globally rename MSTest to be Microsoft.Testing.Framework
• we get many upvotes

[Nirmal4G]

@Evangelink I also propose a new Shared Framework of testing tools and frameworks in .NET SDK along with a new Test SDK for the Project (not just a simple rename). May be not for v4 but for v5 maybe? .NET 10? Basically, a built-in Testing support from the .NET SDK without any external dependencies.

See #3254 for the proposal and discussion.

[Varorbc]

Or import it in the following form.

https://github.com/dotnet/aspire/blob/515f839a532499a46830d3efb557aad9691cd040/src/Aspire.ProjectTemplates/templates/aspire-apphost/Aspire.AppHost1.csproj#L1-L3