MrtCore.PriGen.targets defaults RuntimeIdentifiers to non-portable RIDs - should be dependent on .NET version about windowsappsdk HOT 7 CLOSED

ok thx., what I missed when reading all the different google-results for WinUI 1.5/net8 was that i also have to rename the .pubxml files manually!
But now I also have to use the true again!? (I remember reading somewhere that this is not needed any more....)

Did you ever try what happens if you don't manually rename the publish profiles? As a hint, the build doesn't care. The following is the build output of a package and publish.

Build started at 19:57...
1>------ Build started: Project: CsMeh, Configuration: Release ARM64 ------
1>CsMeh -> C:\Users\Darran\source\repos\CsMeh\CsMeh\bin\ARM64\Release\net8.0-windows10.0.19041.0\win-arm64\CsMeh.dll
1>Optimizing assemblies for size. This process might take a while.
1>ILLink : Trim analysis warning IL2026: WinRT.TypeExtensions.GetAuthoringMetadataType(Type): Using member 'WinRT.TypeExtensions.<>c.<GetAuthoringMetadataType>b__18_0(Type)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. If authoring a WinRT component in C# using C#/WinRT authoring support, it might require ABI helper types that might get trimmed. Avoid marking such components trimmable or ensure types don't get trimmed from it.
1>C:\Users\Darran\.nuget\packages\microsoft.windows.sdk.net.ref\10.0.19041.31\lib\net6.0\WinRT.Runtime.dll : warning IL2104: Assembly 'WinRT.Runtime' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries
1>CsMeh -> C:\Users\Darran\source\repos\CsMeh\CsMeh\bin\Release\net8.0-windows10.0.19041.0\win-arm64\publish\
1>CsMeh -> C:\Users\Darran\source\repos\CsMeh\CsMeh\bin\ARM64\Release\net8.0-windows10.0.19041.0\win-arm64\AppPackages\CsMeh_1.0.0.0_arm64_Test\CsMeh_1.0.0.0_arm64.msix
1>CsMeh -> bin\ARM64\Release\net8.0-windows10.0.19041.0\win-arm64\AppPackages\CsMeh_1.0.0.0_arm64_Test\CsMeh_1.0.0.0_arm64.msixsym
1>Done building project "CsMeh.csproj".
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 19:57 and took 16.400 seconds ==========
A package has been successfully built for Release (x86).
A package has been successfully built for Release (x64).
A package has been successfully built for Release (ARM64).
========== Package: 3 succeeded, 0 failed ===========

The project still has win10-$(Platform) for the PublishProfile setting.

Here is the hint, this file could be named blarghblargh-blerbler.pubxml and Visual Studio wouldn't care. As long as there was some way in the project to distinguish between platforms. That isn't a setting which uses the .NET RID. It is just a file name, and it seems like win10-$(Platform).pubxml was chosen to keep it in line with other things.

So any project created with the 1.4 templates only have the following steps required to make them 1.5/.NET 8 compatible.

1. Edit the .csproj file and either modify the RuntimeIdentifiers to only specify win-x86;win-x64;win-arm64 or you have a conditional one that allows you to switch between .NET versions. The new .csproj template uses the second approach, but you can remove the non portable RIDs if you have no intention of building against an older version of .NET.
2. Edit the .pubxml files to modify the RuntimeIdentifier to only specify the specific identifier in the form of win-x86, win-x64 or win-arm64, or you can have a conditional one that allows you to switch between .NET versions.
3. Update the Windows SDK Build Tools first. Updating the Windows App SDK will fail if it isn't at least 10.0.22621.2428.
4. Update the Windows App SDK to 1.5.

This is ALL you need to do.

So maybe I completely mis-interpreted the 1.5 release note stating that Support for .NET 8 is now 'completed'.

This only ever meant that the Windows App SDK build files would switch between RIDs depending on .NET version used. The project files themselves still need to update the RIDs or use UseRidGraph.
To be more forward compatible, you want to update any RIDs and even potentially rename the .pubxml files. But the .pubxml file names are ok to leave as they are for now.

from windowsappsdk.

Thanks @Scottj1s for finding the root cause here! FYI if anybody else hits this before the issue is fixed, let me explain a bit more with Scott's workaround.

If you upgrade to .NET 8.0 and WinAppSDK 1.5.x+ but you still receive this error, this issue may affect you.
Error NETSDK1083 The specified RuntimeIdentifier 'win10-arm' is not recognized. See https://aka.ms/netsdk1083 for more information. WinAppSDKUI_UT C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 90 Error NETSDK1083 The specified RuntimeIdentifier 'win10-arm-aot' is not recognized. See https://aka.ms/netsdk1083 for more information. WinAppSDKUI_UT C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 90 Error NETSDK1083 The specified RuntimeIdentifier 'win10-arm64-aot' is not recognized. See https://aka.ms/netsdk1083 for more information. WinAppSDKUI_UT C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 90 Error NETSDK1083 The specified RuntimeIdentifier 'win10-x86' is not recognized. See https://aka.ms/netsdk1083 for more information. WinAppSDKUI_UT C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 90 Error NETSDK1083 The specified RuntimeIdentifier 'win10-x86-aot' is not recognized. See https://aka.ms/netsdk1083 for more information. WinAppSDKUI_UT C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 90 Error NETSDK1083 The specified RuntimeIdentifier 'win10-x64' is not recognized. See https://aka.ms/netsdk1083 for more information. WinAppSDKUI_UT C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 90 Error NETSDK1083 The specified RuntimeIdentifier 'win10-x64-aot' is not recognized. See https://aka.ms/netsdk1083 for more information. WinAppSDKUI_UT C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets 90

In this particular issue, the solution did NOT have "win10-x64" or any "win10" anywhere in it anymore, but yet still hit the errors.
WinAppSDK 1.5 should support this now. See https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#suppport-for-net-8

However, this was a Unit Test that had a reference to the WinAppSDK project. Previous to .NET8.0 and WinAppSDK1.5.1 it had no RuntimeIdentifiers present, and compiled just fine. After the upgrade you get the error messages.

The workaround until this is fixed is this
<PropertyGroup> <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers> </PropertyGroup>

from windowsappsdk.

I am confused completely now!
Just spent some hours only to get a new empty project with Win UI3 1.5.x and net8 to run.
Using VS 17.9.4 running on Windows 11 Pro 23H2 22631.3296

My Project template "Blank App, packaged(WinUI 3)" does create a project with nuget refs:

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.4.230913002" />
<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.755" />

This template has the "win10-xy" in the runtime identifiers. Is there a way to update this templates to current versions ?

What I did from there on:

• Upgrade both nuget pkgs to latest version. ( "1.5.240311000", "10.0.22621.3233" )
• Change the target framework to ".NET 8.0" in VS Property page (this creates the line <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework> in the project file. Is this correct?)
• change the line win-x86;win-x64;win-arm64 manualy
• AND remove the "10" from the <PublishProfile>win10-$(Platform).pubxml</PublishProfile>

now the project compiles and runs but there is still the warning:

1>C:\Program Files\dotnet\sdk\8.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(284,5): warning NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): win10-arm64, win10-x64, win10-x86. Affected libraries: Microsoft.WindowsAppSDK. In .NET 8.0 and higher, assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.

What exactly does the "In 1.5, we completed that work so that the warning is no longer present." at https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#suppport-for-net-8 really mean?

Could you pls. point me to or provide some "HOW to" for

1. Make VS ready to have latest versions available & usable
2. Create clean New Project with 1.5.x/net8
3. Make clean upgrade of older projects/solutions

from windowsappsdk.

Sorry to hear. It’s a bit confusing and I guess the templates needs fixing. Maybe you can file a new issue for the template issue once you get this working?

The release notes mention the steps which worked for me (buried though).

As a step, You also need to rename the .pubxml files

Aside from the template being older, if you need to upgrade the release notes are far from perfect. You need to piece together info from multiple older notes
https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#suppport-for-net-8

“You'll also need to update the property in the .csproj file to win-x86;win-x64;win-arm64, as well as update each Propeties*pubxml file to switch from win10 to win in the property (for example, win-x86).”

P.S. This particular issue only happens when consuming via dependency a WinAppSDK 1.5+ / .NET8.0 project

from windowsappsdk.

@RobertK66 @ivberg
The issue seems to be that the templates are distributed as part of Visual Studio, and there appear to be times when the packages that are part of Visual Studio can go through a major change. This isn't the first time that there has been changes to the project templates that did not become available for a while.
Currently, at the very least, packages will update at larger version updates. The next one will be 17.10. This doesn't guarantee that it will be 17.10 though. Right now, you can find the project templates in the repository. This means that you can make the changes manually for now.

from windowsappsdk.

@DarranRowe: ok, understood about templates.
Unfortunately now my Q-2 is obsolete and I have to go to Q-3 "How to make a clean update from 1.4/net6 to 1.5/net8".

@ivberg : ok thx., what I missed when reading all the different google-results for WinUI 1.5/net8 was that i also have to rename the .pubxml files manually!
But now I also have to use the <UseRidGraph>true</UseRidGraph> again!? (I remember reading somewhere that this is not needed any more....)

So maybe I completely mis-interpreted the 1.5 release note stating that Support for .NET 8 is now 'completed'. I expected it to work without tweaking in the proj files. So actually the Known Issue from 1.4 ( https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#known-issues-1 ) still applies? Or is this now a tools/Visual Studio problem (as the templates are for sure)?

PS: sorry for hijacking this - unrelated - issue. I will try to use the templates from repository and open new specific issue(s) if my confusion remains ...

from windowsappsdk.

Ok, had time to check your Step by Step instruction. What I didn't catch until now, was that at step 2. I have to change the content of the .pubxml files (as stated the <RuntimeIdentifier> ) ! As stated, renaming is not needed!

What I am now left with is another warning complaining about other content of the .pubxml files:

`The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'PublishProtocol' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'.....

This is only IntelliSense warning, disappearing when the pubxml editor tabs are closed! (I think the template in your repos still has this node in. Is it needed? Should it be replaced with other one?)

The build itself now is clean.
Thx. for your support.

from windowsappsdk.