sdk: 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]

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 5
Comments: 24 (15 by maintainers)

Most upvoted comments

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.

sr55 on Jul 28, 2021

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

AArnott on Nov 12, 2021

@vatsan-madhavan We have a bug in 5.0.400 where the work to enable the WindowsDesktop arm64 support that was checked into 5.0.3xx didn’t make it into the 5.0.400 release. I’m working on updating our release notes for it and the issue is already resolved and planned for 5.0.401.

https://github.com/dotnet/installer/issues/11481 <-- related bug https://github.com/dotnet/installer/pull/11458 <-- Fixed issue

marcpopMSFT on Aug 16, 2021

That issue started on Friday so anyone having problems before then would not be from that issue. Certainly anyone hitting it between the 23rd and 27th only could have been affected by the outage.

Per above, setting self-contained to false works around this as we only use the runtime packs for self-contained applications. Given this is an old issue, I’m having trouble tracking if it’s just the VS publish that’s still broken or CLI publish as well.

marcpopMSFT on Jul 28, 2021