The latest win22 release broke some dotnet SDK build steps

[yuyoyuppe]

Description

This change introduced 2 issues for us.

1. Our source generator fails to build:

C:\Program Files\dotnet\sdk\9.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(262,5): error NETSDK1216: Package Microsoft.Net.Sdk.Compilers.Toolset is not downloaded but it is needed because your MSBuild and SDK versions are mismatched. Ensure version 9.0.300 of the package is available in your NuGet source feeds and then run NuGet package restore from Visual Studio or MSBuild. [C:\a\repo\SourceGenerator.csproj]

We're building for dotnet 8, and we didn't have global.json. Creating one with the following contents fixed the issue:

{
  "sdk": {
    "version": "8.0.300"
  }
}

But then our .msix installer would fail to be installed on the CI (we do some smoke test on CI and install our installer as part of them):

Windows cannot install package <msix> because this 
package depends on a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.UWPDesktop" 
published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 
processor architecture and minimum version 14.0.33728.0, along with this package to install. The frameworks with name 
"Microsoft.VCLibs.140.00.UWPDesktop" currently installed are: {}

For now we've installed Microsoft.VCLibs.x64.14.00.Desktop.appx manually.

Related:

• V 1.9 Breaks Winget PowerShell Module (Microsoft.VCLibs.140.00.UWPDesktop Issue) microsoft/winget-cli#4916
• The error "Unable to find package Microsoft.Net.Sdk.Compilers.Toolset with version (= 10.0.100-alpha.1.24556.12)" appeared when creating the .NET project based on latest .NET SDK 10.0 with 17.12.0 Preview 5.0 dotnet/sdk#44703

Sorry if it's a wrong place to report, just thought it'd be useful to add visibility here, as it wasn't happening on all previous runner versions for a while.

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

  Image: windows-2022
  Version: 20250527.1.0

Is it regression?

yes, it worked on 20250511.1.0

Expected behavior

The build doesn't fail.

Actual behavior

The build fails.

Repro steps

It's a bit hard to give exact repro steps as the repo is private, but, as described above, it's just a dotnet 8 project.

[xincheng213618]

I have encountered this issue as well. You can refer to this link for more details: https://github.com/xincheng213618/scgd_general_wpf/actions/runs/15402999897

[BlairMcClelland]

We applied the fix described here to workaround it

https://developercommunity.visualstudio.com/t/Azure-Pipeline-image-2025052710-is-mis/10913159#T-N10914458
https://www.nuget.org/packages/Microsoft.Net.Sdk.Compilers.Toolset/9.0.300#readme-body-tab

 dotnet restore /p:BuildWithNetFrameworkHostedCompiler=true

[xincheng213618]

Thank you very much! I changed the step in the action from:

- name: Restore dependencies
  run: dotnet restore build.sln

to:

- name: Restore dependencies
  run: dotnet restore build.sln /p:BuildWithNetFrameworkHostedCompiler=true

and now it works.

[kishorekumar-anchala]

Hi @yuyoyuppe - Thank you for bringing this issue to our attention. We will look into this issue and will update you after investigating.


[subir0071]

Hi @yuyoyuppe - Could you please share a rudimentary public workflow that helps reproduce this issue?
If your issue is similar to this workflow failure, shared by @xincheng213618, then , please use the workaround provided in this comment or use the below msbuild buld command to restore and build your project.

    - name: Build C++ project with MSBuild
      run: |
        msbuild build.sln /restore /p:Configuration=Release /p:Platform=x64

Please go through the below workflow file with successful restore and build of the project -
https://github.com/subir0071/scgd_general_wpf/actions/runs/15426069096/workflow

Let us know how to it goes.

[craigbrown]

We're seeing this issue as well, but on Azure DevOps. Here's a minimal example yaml file which reproduces the issue.

trigger: none

pool:
  vmImage: 'windows-latest'

steps:
- checkout: none

- task: PowerShell@2
  displayName: 'Create .NET 9 console app and solution'
  inputs:
    targetType: inline
    script: |
      mkdir src
      cd src

      # Create console app
      dotnet new console -n DotNet9App -f net9.0
      cd DotNet9App

      cd ..

      # Create a solution and add the project
      dotnet new sln -n DotNet9Solution
      dotnet sln add .\DotNet9App\DotNet9App.csproj

- task: VSBuild@1
  displayName: 'Build solution with VSBuild'
  inputs:
    solution: 'src/DotNet9Solution.sln'
    msbuildArgs: '/p:Configuration=Release'
    platform: 'Any CPU'
    configuration: 'Release'

The task VSBuild@1 fails with the error:

##[error]C:\Program Files\dotnet\sdk\9.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(262,5): Error NETSDK1216: Package Microsoft.Net.Sdk.Compilers.Toolset is not downloaded but it is needed because your MSBuild and SDK versions are mismatched. Ensure version 9.0.300 of the package is available in your NuGet source feeds and then run NuGet package restore from Visual Studio or MSBuild.
C:\Program Files\dotnet\sdk\9.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(262,5): error NETSDK1216: Package Microsoft.Net.Sdk.Compilers.Toolset is not downloaded but it is needed because your MSBuild and SDK versions are mismatched. Ensure version 9.0.300 of the package is available in your NuGet source feeds and then run NuGet package restore from Visual Studio or MSBuild. [D:\a\1\s\src\DotNet9App\DotNet9App.csproj]

[sebastiannordby]

Same problem on Azure Devops. Fails with VSBuild@1.

[dbeusink]

Can confirm having the same issue on Azure DevOps; I also replied to this thread on Developer Community.

Adding

- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '9.0.203'

is a workaround for repositories targeting .NET 9 but breaks VSTest for repositories targeting .NET 8.
This issue is now active for a few days; kindly investigate as this is impacting our development flow at the moment.

EDIT:
Adding /restore and /p:BuildWithNetFrameworkHostedCompiler=true to the msbuildArgs input of our VSBuild@1 task seems to be a workaround that works across all our pipelines (.NET Framework, .NET 8 and .NET 9).

Configuration in our pipeline:

      # Restore NuGet packages
      - task: DotNetCoreCLI@2
        displayName: 'Restore NuGet'
        inputs:
          command: 'restore'
          projects: '${{ parameters.solution }}'
          feedsToUse: 'config'
          nugetConfigPath: 'MHS.Build\nuget.config'
          includeNuGetOrg: false
          verbosityRestore: 'Minimal'

      # Build: no-packaging
      - ${{ if eq(parameters['strategy'], 'no-packaging') }}:
          - task: VSBuild@1
            condition: succeeded()
            displayName: "Build (no-packaging)"
            inputs:
              solution: '${{ parameters.solution }}'
              msbuildArgs: '/restore /p:GeneratePackageOnBuild=false /p:BuildWithNetFrameworkHostedCompiler=true'
              ${{ if ne(parameters['vsConfigurationOverride'], '') }}:
                configuration: '${{ parameters.vsConfigurationOverride }}'
              maximumCpuCount: true