Publish of WPF app fails for ARM64 - "There was no runtime pack"

Using .NET 6 Preview 1, trying to publish a WPF app for ARM64 fails with

1>There was no runtime pack for Microsoft.WindowsDesktop.App available for the specified RuntimeIdentifier 'win-arm64'.

Repro:

• Clone https://github.com/NuGetPackageExplorer/NuGetPackageExplorer
• Checkout the arm64-support branch.
• dotnet publish -c release .\PackageExplorer\NuGetPackageExplorer.csproj /p:PublishProfile=Properties\PublishProfiles\WinARM64.pubxml

 pwsh> dotnet publish -c release .\PackageExplorer\NuGetPackageExplorer.csproj /p:PublishProfile=Properties\PublishProfiles\WinARM64.pubxml
Microsoft (R) Build Engine version 16.9.0-preview-21103-02+198f3f262 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored D:\dev\NuGetPackageExplorer\PackageExplorer\NuGetPackageExplorer.csproj (in 801 ms).
  Restored D:\dev\NuGetPackageExplorer\PackageViewModel\PackageViewModel.csproj (in 801 ms).
  Restored D:\dev\NuGetPackageExplorer\Core\Core.csproj (in 1.07 sec).
  1 of 4 projects are up-to-date for restore.
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
C:\Program Files\dotnet\sdk\6.0.100-preview.1.21103.13\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(389,5): error NETSDK1082: There was no runtime pack for Microsoft.WindowsDesktop.App available for the specified RuntimeIdentifier 'win-arm64'. [D:\dev\NuGetPackageExplorer\Core\Core.csproj]

[sr55]

I ran into this issue as well however I’ve now managed to get past it. I’m using dotnet publish with a defined profile.

In my profile file, I have the following:

<RuntimeIdentifier>win-arm64</RuntimeIdentifier>
**<SelfContained>false</SelfContained>**                                 
<PublishSingleFile>True</PublishSingleFile>
**<PublishReadyToRun>false</PublishReadyToRun>**

The two highlighted, have to be set to false. Makes sense I guess but the error is very unintuitive.

I also got caught out with one of my dependencies hooking a .NET Framework DLL (which is a no-go) but alas, different issue but something to watch out for too 😃

Hopefully this is helpful to some.

[AArnott]

@wli3 Why was this closed? It still repros on the 6.0.100 SDK. I opened #22565 to track.