Repository navigation
[Windows] Controls.Sample.Sandbox cannot be compiled with PublishReadyToRun=True #22952
Description
Activity
Hi I'm an AI powered bot that finds similar issues based off the issue title.
Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!
Closed similar issues:
- VisualStudio Maui templates not working in release (#12515), similarity score: 0.71
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
- changed the title
[-]`Controls.Sample.Sandbox` cannot be compiled with `PublishReadyToRun=True`[/-][+][Windows] `Controls.Sample.Sandbox` cannot be compiled with `PublishReadyToRun=True`[/+]on Jun 10, 2024 Can repro this issue at Windows platform on the latest 17.11.0 Preview 2.0(8.0.70-ci.net8.24316.1&8.0.70-ci.net8.24314.1).
Environment
Tested with dotnet
9.0.100-preview.6.24328.19and https://github.com/dotnet/maui/tree/net9.0 (73dc3d7).Test
cd src/Controls/samples/Controls.Sample.Sandbox dotnet build dotnet publish -f net9.0-windows10.0.19041 -c Release -p:PublishReadyToRun=true -p:WindowsPackageType=None # Interestingly, I had to use `net9.0-windows10.0.19041` and not `net9.0-windows10.0.19041.0` (i.e. the trailing zero is missing)
And it fails with:
Graphics net9.0-windows10.0.19041 failed with 1 error(s) (0,1s) C:\Program Files\dotnet\sdk\9.0.100-preview.6.24328.19\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(400,5): error NETSDK1094: Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing. When targeting .NET 6 or higher, make sure to restore packages with the PublishReadyToRun property set to true.When I ran with
-p:PublishReadyToRun=false:dotnet publish -f net9.0-windows10.0.19041 -c Release -p:PublishReadyToRun=false -p:WindowsPackageType=None
the publish process finished.
So the issue appears to be present even in .NET 9.
Did you try using a runtime identifier as the error states?
I checked out 0fae06d and tested with that.
No RID
Originally, the issue was reported for .NET 8, now .NET 9 is released, so just to recap:
dotnet publish -f net9.0-windows10.0.19041.0 -c Release -p:PublishReadyToRun=True -p:WindowsPackageType=Nonereports the following error for me
Graphics net9.0-windows10.0.19041.0 failed with 1 error(s) (1,2s) C:\Program Files\dotnet\sdk\9.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(400,5): error NETSDK1094: Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing. When targeting .NET 6 or higher, make sure to restore packages with the PublishReadyToRun property set to true.With a RID
When I specify the
win-x64RID1:dotnet publish -f net9.0-windows10.0.19041.0 -c Release -r win-x64 -p:PublishReadyToRun=True -p:WindowsPackageType=Nonethen I get the following errors:
Z:\maui\src\Essentials\src\Essentials.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.Mono.win-x64 with version (= 9.0.0) - Found 102 version(s) in dotnet-public [ Nearest version: 9.0.0-preview.7.24405.7 ] - Found 0 version(s) in C:\Program Files\dotnet\library-packs - Found 0 version(s) in benchmark-dotnet-prerelease - Found 0 version(s) in darc-pub-dotnet-maui-a33a875e - Found 0 version(s) in dotnet-eng - Found 0 version(s) in dotnet-libraries-transport - Found 0 version(s) in dotnet-libraries - Found 0 version(s) in dotnet-tools - Found 0 version(s) in skiasharp Z:\maui\src\Core\maps\src\Maps.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.Mono.win-x64 with version (= 9.0.0) - Found 102 version(s) in dotnet-public [ Nearest version: 9.0.0-preview.7.24405.7 ] - Found 0 version(s) in C:\Program Files\dotnet\library-packs - Found 0 version(s) in benchmark-dotnet-prerelease - Found 0 version(s) in darc-pub-dotnet-maui-a33a875e - Found 0 version(s) in dotnet-eng - Found 0 version(s) in dotnet-libraries-transport - Found 0 version(s) in dotnet-libraries - Found 0 version(s) in dotnet-tools - Found 0 version(s) in skiasharp ...Unrelated but I noticed that
UseRidGraphseems to betrueby default:I'm not sure how it plays together with this.
Footnotes
-
I tried
win10-x64as well but it is not recognized which is as expected I guess since there were some RID changes. ↩
-
You can't use the
-rparameter because WinUI issues:- During publish the RuntimeIdentifier should not be used when determining the outputs of referenced class libraries microsoft/WindowsAppSDK#4618
dotnet publishresults in an error about duplicate files microsoft/WindowsAppSDK#3337
Add this to the csproj:
<PropertyGroup Condition="'$(RuntimeIdentifierOverride)' != ''"> <RuntimeIdentifier>$(RuntimeIdentifierOverride)</RuntimeIdentifier> </PropertyGroup>
and then set that property on the CLI:
dotnet publish -f net9.0-windows10.0.19041.0 -c Release -p:RuntimeIdentifierOverride=win-x64 -p:PublishReadyToRun=True -p:WindowsPackageType=NoneOh dear, the
UseRidGraphwas supposed to be false for net9 - but I also think the fixes we need from WinUI only came in late so not much we can do now.I even had an issue, sigh: #17142
- locked and limited conversation to collaborators
on Nov 22, 2024
Description
I created a few PRs to improve performance for MAUI on Windows. The effect of my PRs are IMO affected by the fact that
PublishReadyToRun=Truecannot be set when compilingControls.Sample.SandboxMAUI project.Steps to Reproduce
Check out the latest
maincommit b182ffe and run:then:
and it reports
However,
PublishReadyToRun=Falseworks just fine:Link to public reproduction project repository
No response
Version with bug
Nightly / CI build (Please specify exact version)
Is this a regression from previous behavior?
No, this is something new
Last version that worked well
Unknown/Other
Affected platforms
Windows
Affected platform versions
No response
Did you find any workaround?
No.
Relevant log output
No response