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:

• https://github.com/microsoft/winget-cli/issues/4916
• https://github.com/dotnet/sdk/issues/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
• [x] 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
• [x] 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

[oleaalarsen]

Same issue. Broke pretty much all our pipelines. Mix of latest dotnet and .net framework

[jnyrup]

It might be related to #12274 I experienced the same error when building a C# projects in a pipeline using a Visual Studio instead of plain dotnet build. The machine had VS 17.12 or 17.13 installed and dotnet 9.0.300. Upgrading VS to 17.14 solved the issue for me.

[subir0071]

Hi @jnyrup - We are working towards putting VS 17.14 in the runner images.

[haldiggs]

Same issue. Broke pretty much all our pipelines. Mix of latest dotnet and .net framework

yes broke the msbuild pipelines on our side as well. still have to use msbuild because of COM files

for some reason commenting out the dotnet restore and adding the /restore to the msbuild command allows it to run

#- name: Restore dependencies
#  run: dotnet restore ${{env.SOLUTION_FILE_PATH}}

- name: Build
    run: msbuild ${{env.SOLUTION_FILE_PATH}} /restore /m /p:Configuration=${{env.BUILD_CONFIGURATION}}

[subir0071]

Upgrade to VS version 17.14 should resolve this issue. We are working to rollout the same.

[buckleyGI]

@subir0071 Will this then prevent the workarounds documented at https://developercommunity.visualstudio.com/t/Azure-Pipeline-image-2025052710-is-mis/10913159?sort=newest&viewtype=all ? Thank you

[JSparshottO2]

We're also hit with this in Azure DevOps similar to others on this thread. We've referenced the package as a workaround but we really shouldn't need to reference it. Any ETA on a fix for the DevOps agents?

[subir0071]

We are rolling out visual studio 17.14 this week. https://github.com/actions/runner-images/pull/12423

[subir0071]

Visual studio 17.14 has been rolled out. Let us know if this issue is resolved.

[xincheng213618]

Visual studio 17.14 has been rolled out. Let us know if this issue is resolved.

I have tested the new version, and after removing the previous fix, everything is now working as expected.

[craigbrown]

Hi @subir0071 , thanks for the update.

May I ask if your team is planning on looking at how this happened/how it can be prevented from happening again?

This seems to have affected a lot of people – it broke quite a common use-case of building a .NET project with MSBuild. I'm surprised that this wasn't caught before it was rolled out, and that it took two weeks to roll out a fix.

[subir0071]

Hello @craigbrown - We understand and apologize for the inconveniences caused.

The issue stemmed from the mismatch in the installed version of dotnet and Visual Studio. Dotnet Version 9.0.301 supports Visual Studio version 17.14, but it took us few weeks more to get to that VS version installed. Our VS version upgrade has some manual tasks, which we are looking to get rid of.

Hopefully, this issue would not occur after the fix is in place.

Thanks to all community members for raising, debugging and collaboratively working towards resolving this issue.