DotNet test runs fail for a x86 projects - Microsoft.WindowsDesktop.App (net core 6) is missing on windows-latest runner,

[kerrywicks]

Description:
This has been an issue since Wednesday 22nd November. DotNet test runs fail for a x86 projects with an error message stating that Microsoft.WindowsDesktop.App (net core 6) is missing on windows-latest (github action) runner.

This issue was raised here: actions/runner-images#8859 (reported as an Azure devops issue), but was closed with a claim that it is not image related, and it was recommended to raise the issue here. I'm hoping this is the right place to raise this! If I should raise this elsewhere, please let me know and feel free to close this.

Task version:
setup-dotnet@v3

Platform:
Windows

Runner type:
Hosted - github action + Azure devops

Repro steps:
Here are the tasks I am attempting to run:

# Setup
- name: Install .NET Core
  uses: actions/setup-dotnet@v3
  with:
    dotnet-version: 6.0.x

This task does pass, but gives the message:

dotnet-install: .NET Core SDK with version '6.0.417' is already installed.

The next task is to run the unit tests for a windows app project:

- name: Execute Domino.UnitTests.LabelFacade
  run: dotnet test ".\Mozart\Domino.UnitTests.LabelFacade\bin\x86\Release\net6.0-windows\Domino.UnitTests.LabelFacade.dll" --verbosity m

This task fails with the following message:

Testhost process for source(s) 'D:\a\DA-development\DA-development.\Mozart\Domino.UnitTests.LabelFacade\bin\x86\Release\net6.0-windows\Domino.UnitTests.LabelFacade.dll' exited with error: You must install or update .NET to run this application.
App: D:\a\DA-development\DA-development\Mozart\Domino.UnitTests.LabelFacade\bin\x86\Release\net6.0-windows\testhost.x86.exe
Architecture: x86
Framework: 'Microsoft.WindowsDesktop.App', version '6.0.0' (x86)
.NET location: C:\Program Files (x86)\dotnet
The following frameworks were found:
8.0.0 at [C:\Program Files (x86)\dotnet\shared\Microsoft.WindowsDesktop.App]

Expected behavior:
I'd expect .net 6 to install if it is in fact missing for both x86 and x64, and as such I would expect the testhost to be able to run tests successfully.

Actual behavior:
The image thinks that .Net is installed at the requested version - however, the x86 portion for .net tests seem to be missing. Note that x86 non-test projects build and run successfully as expected.

[dusan-trickovic]

Hello, @kerrywicks ! Thank you for reporting this issue, we will look into it :)

[MelDommer]

We are also seeing this issue for x86 tests. Started within the last 2 weeks.

[mnr3395]

We are also facing the issue for x86 tests from last week

[fredrikloch]

We are having the same issue in our builds, starting on the 20th of November. Our current workaround is to use a self hosted agent where we manually install windows desktop development packages.
Attaching a msbuild.zip from a build that fails using this following build configuration:

trigger: none
jobs:
##
# Configuration
##
- job: Build_HSH
  pool:
    vmImage: 'windows-latest'
  steps:

    - checkout: self  # self represents the repo where the initial Pipelines YAML file was found
      clean: true  # whether to fetch clean each time
      submodules: true

    - task: UseDotNet@2
      inputs:
        packageType: 'sdk'
        version: 6.x
        performMultiLevelLookup: true

    - task: UseDotNet@2
      inputs:
        packageType: 'runtime'
        version: 6.x
        performMultiLevelLookup: true

    - powershell: |
        dotnet --info
      displayName: 'dotnet info'

    - powershell: dotnet tool restore
      displayName: 'dotnet tool restore'

    - powershell: |
        dotnet --info
      displayName: 'dotnet info'
      
    - task: DotNetCoreCLI@2
      displayName: 'Test HSH'
      inputs:
        command: 'test'
        arguments: "-s test.runsettings -v:n --logger:trx /bl"

    - task: PublishBuildArtifacts@1
      displayName: 'Publish Artifact: build-log'
      condition: always()
      inputs:
        PathtoPublish: '$(Build.Repository.LocalPath)/msbuild.binlog'
        ArtifactName: 'build-log'

To trigger the issue, we've used the following csproj settings:
"Code project"

  <PropertyGroup>
    <TargetFramework>net6.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
    <Platforms>x86</Platforms>
    <Configurations>Debug;Release</Configurations>
    <Nullable>enable</Nullable>
    <IsPackable>false</IsPackable>
    <implicitUsings>enable</implicitUsings>
  </PropertyGroup>

"Test project"

  <PropertyGroup>
    <TargetFramework>net6.0-windows</TargetFramework>
    <Platforms>x86</Platforms>
    <Configurations>Debug;Release</Configurations>
    <Nullable>enable</Nullable>
    <ImplicitUsings>true</ImplicitUsings>
  </PropertyGroup>

[phil6789]

Same her. VSTest@2 doesnt work either.
Changed my 2 NET6 unit test projects (one for x86 one for x64) to NET8, the assembly under test itself remains NET6.
Works again. 😃

[brenda-vh]

I have a fork that fixes the issue but would like it resolved upstream. This is just a hack to make sure we have the right dotnet version. It should be supported properly by Github Actions IMO.

[priya-kinthali]

Hello @kerrywicks 👋,
Apologies for the delay in response. Could you please let us know if this issue is still relevant to you or it has been resolved? If it is still relevant, could you kindly provide a minimal reproduction or a sample repository link to help us reproduce the issue? Thank you!

[kerrywicks]

Hi Priya - this issue is no longer relevant to us as we upgraded to .net 8.0. Our workaround was to run our test processes on an upgraded version of .Net at the time, if I remember rightly - though it has been a while! I have no idea if others are still facing this issue or not. I'd imagine that given this issue is almost a year old now (happy birthday for tomorrow to this issue!) that anyone affected found a work-around.

[priya-kinthali]

Hello @kerrywicks 👋,
Thank you for your response and for letting us know that the issue is no longer relevant after upgrading to .NET 8.0. We truly appreciate your feedback and are glad to hear that the workaround helped! 😊
As the issue has been resolved for you, we will proceed to close this issue. Please feel free to reach out to us in case of any other concerns. Thank you for your understanding and cooperation!