Using Microsoft.NET.Test.Sdk as GlobalPackageReference breaks the build

[astaerk]

Description

When using the package Microsoft.NET.Test.Sdk as GlobalPackageReference in a Directory.Packages.props the build fails with this error:

CS0234	The type or namespace name 'TestPlatform' does not exist in the namespace 'Microsoft.VisualStudio' (are you missing an assembly reference?)	
Project1.Tests	
%UserProfile%\.nuget\packages\microsoft.net.test.sdk\17.10.0\build\netcoreapp3.1\Microsoft.NET.Test.Sdk.Program.cs	3	

Using it as normal PackageReference in the .csproj works fine.

Steps to reproduce

• create a new project
• create a Directory.Packages.props and set ManagePackageVersionsCentrally = true
• add <GlobalPackageReference Include="Microsoft.NET.Test.Sdk" Version="17.10.0" />
• Build

I created a small repo to demonstrate the issue:
https://github.com/proj-arch/Microsoft.NET.Test.Sdk-GlobalPackageReference-BuildError

Expected behavior

the project can be successfully built

Actual behavior

the build breaks with the error

CS0234	The type or namespace name 'TestPlatform' does not exist in the namespace 'Microsoft.VisualStudio' (are you missing an assembly reference?)	
Project1.Tests	
%UserProfile%\.nuget\packages\microsoft.net.test.sdk\17.10.0\build\netcoreapp3.1\Microsoft.NET.Test.Sdk.Program.cs	3	

Diagnostic logs

Since the build fails, I cannot run the tests with diagnostics.

Environment

• Windows 10 22H2 (Build 19045.4529)
• Visual Studio Enterprise 2022 17.10.1
• vstest.console 17.10.0
• Microsoft.NET.Test.Sdk package in version 17.10.0

[nohwnd]

It looks like non of the lib files are referenced, adding this test code:

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Project1.Tests
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMethod1()
        {
        }
    }
}

Which is a standard test class also tells me that TestClass and TestMethod does not exist. I could not find similar issue reported with GlobalPackageReference, but the nugets look standard, and we produce them from different workflows, so this looks more like the package management problem.

@MichalPavlik have you seen such problem with global package management before?