SDK-style projects misdetected as "traditional .NET Framework" when the SDK is referenced via a transitively-imported <Import Sdk="…">

[JakeRadMSFT]

Describe the bug

C# Dev Kit misclassifies SDK-style projects as "traditional .NET Framework / unsupported" when the project references the SDK via an <Import Sdk="…"> element that lives in a transitively-imported file rather than on the top-level <Project> element.

The SDK-style detection appears to be a shallow scan of the project's own XML: it recognizes <Project Sdk="…"> (attribute form) and a direct in-file <Import Sdk="…">, but it does not resolve a plain <Import Project="…"> to discover an <Import Sdk="…"> that lives in the imported file. A full MSBuild evaluation classifies these correctly as SDK-style.

Repro

Create a project whose top-level file has no direct SDK reference, importing a shared file that carries the SDK import (a common pattern for multi-RID packaging projects):

<!-- Outer.csproj -->
<Project>
  <PropertyGroup>
    <SomeRuntime>osx-arm64</SomeRuntime>
  </PropertyGroup>
  <Import Project="Common.projitems" />
</Project>

<!-- Common.projitems -->
<Project>
  <Import Sdk="Microsoft.NET.Sdk" Project="Sdk.props" />
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <Import Sdk="Microsoft.NET.Sdk" Project="Sdk.targets" />
</Project>

Open the folder in workspace-based development mode.

Expected behavior

Outer.csproj is recognized as SDK-style and loads (the <Import Sdk="…"> explicit-import form is fully valid and semantically equivalent to <Project Sdk="Microsoft.NET.Sdk">).

Actual behavior

The project is reported as unsupported and fails to load, with these two log signatures:

[warning] The project file '…/Outer.csproj' is in unsupported format (for example, a
          traditional .NET Framework project). It need be converted to new SDK style to
          work in C# Dev Kit.
[error]   Failed to load project '…/Outer.csproj'. One or more errors occurred.
          (This project is not supported in C# Dev Kit.)

Because these are (incorrectly) treated as unsupported, they inflate the red status-bar "N Project(s) failed to be loaded" count.

Additional evidence

In one repro folder, 22 such projects were consistently misclassified as "traditional .NET Framework." Across runs the total failed count moved between 22 and 29 purely because a separate, genuine set of 7 SDK-resolution failures came and went — the 22 explicit-import projects failed every single run, isolating this as a distinct, deterministic detection defect.

Environment

• OS: macOS
• VS Code: 1.130.0-insider (commit e5381e4f)
• C# Dev Kit (prerelease): 3.27.199
• C# extension: 2.147.46

[JakeRadMSFT]

Screenshots

The "unsupported format" notification shown for these (actually SDK-style) projects:

The resulting red "N Project(s) failed to be loaded" status-bar indicator (inflated by these misclassified projects):

[JakeRadMSFT]

Workaround

Until the detection is fixed, you can make the project recognizable as SDK-style by adding a <TargetFramework> (or <TargetFrameworks>) property to the top-level project file — the detection looks for it there. Because the value is set again by the imported file (and imports are evaluated after), re-declaring the same value in the outer file is harmless and does not cause a duplicate-SDK-import problem:

<Project>
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <Import Project="Common.props" />
</Project>

This lets the project load without restructuring the shared-import pattern.