Repository navigation
NativeAOT publishing with MSBuild doesn't work with .NET 8 SDK #89659
Description
Description
I'm trying to build my ComputeSharp WASDK Win32 CLI sample with NativeAOT using the preview .NET 8 SDK (especially because .NET 7 builds fail at runtime due to #84908), but I'm unable to actually get a publish build to be created correctly. I'm oing exactly the same steps I did previously, but it seems when I use the .NET 8 SDK, I just get a normal CoreCLR publish build? 🤔
Reproduction Steps
Baseline (.NET 7)
- Checkout Sergio0694/ComputeSharp@70f8000
- Open a VS Developer PowerShell prompt (need MSBuild)
- Go to folder and publish:
cd samples\ComputeSharp.SwapChain.D2D1;
msbuild ComputeSharp.SwapChain.D2D1.csproj -t:restore,publish /p:Configuration=Release /p:Platform=x64 /p:RuntimeIdentifier=win10-x64;Verify that the publish folder has the expected NativeAOT .exe file.
Of course, it'll crash at startup after the first frame, due to #84908.
Regression (.NET 8)
- Checkout Sergio0694/ComputeSharp@773f8c4
- Open a VS Preview Developer PowerShell prompt (need MSBuild and the .NET 8 Preview SDK)
- Go to folder and publish:
cd samples\ComputeSharp.SwapChain.D2D1.Cli;
msbuild ComputeSharp.SwapChain.D2D1.Cli.csproj -t:restore,publish /p:Configuration=Release /p:Platform=x64 /p:RuntimeIdentifier=win10-x64Observe how the publish folder actually has a lot of random stuff from what seems to be a normal publish build.
In fact, trying to open shows it's not even self-contained, as it's presumably using the default settings:
Expected behavior
I would expect a NativeAOT publish build to be created, just like on .NET 7.
Actual behavior
I end up getting a normal publish build with default settings, and not a NativeAOT one.
Regression?
Yes (works on .NET 7).
Configuration
- .NET 7.0.306
- .NET 8.0.100-preview.7.23364.32
- Windows 11 Enterprise 22621.1992
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
am11 commentedon Jul 29, 2023
Does it work with the top-level
-restoreoption?Sergio0694 commentedon Jul 29, 2023
Alright I fixed it, there were a few problems:
-t:restore,publishdoesn't work with the .NET 8 SDK, had to use/restore -t:publish, same as @am11 suggested (fixed in Fix NativeAOT publishing for Win2D CLI sample, update CI script Sergio0694/ComputeSharp#545). Not sure why it worked with the .NET 7 SDK.win10-x64as RID towin-x64, and WASDK wasn't updated for that yet. @jkoritzinsky said he'd let the team now. In the meantime, I could work around it by adding/p:RuntimeIdentifiers=win-x64./p:RuntimeIdentifier=win10-x64otherwise the building wouldn't copy the native .dll from Win2D to the output directory.For this last part, @MichalStrehovsky is this something that should be handled by the SDK, by WASDK, or is this something we should fix on Win2D's end? Not sure where to report that or whether that's something we can fix ourselves 😄
Eg. once .NET 8 goes stable and we update our package, should we change these folders? 🤔
NCLnclNCL commentedon Jul 30, 2023
Dont use net8 preview 7, you cannot build with it
AaronRobinsonMSFT commentedon Jul 30, 2023
Is this something all SDKs will need to respond to? I believe this was the RID update work. Are there other SDK teams we should contact?
/cc @elinor-fung
jkoritzinsky commentedon Jul 30, 2023
So I was a little wrong on the SDK part of the rid problem. The actual problem was that the WinAppSDK sets the RuntimeIdentifiers property to include Windows-ARM RIDs, which aren't supported.
The fact that the package puts files into the win10-* rid folders is a problem as the breaking change with the RID graph will affect packages like that.
Sergio0694 commentedon Jul 30, 2023
Oh... What would the correct way to handle that on Win2D's side then, should we just update our two packages to use
win-folders and update our targets? Would this mean that this would then only work for .NET 8+, but not work anymore for anyone on .NET 7 or below? And would this be transparent to C++ consumers, I suppose? 🤔jkoritzinsky commentedon Jul 30, 2023
Unless you need to use separate APIs for each Windows version, just use the win- folders and it’ll still work downlevel.
Sergio0694 commentedon Jul 30, 2023
Perfect. Yeah no, we ship the same .winmd/.dll for all versions of Windows, so we can then just fix the folders then 👍
Thank you! 😄
Should I close this issue? I assume the issue with WASDK is tracked separately?
jkoritzinsky commentedon Jul 30, 2023
I haven’t had a chance to file an issue on WASDK, so let’s leave this open until I do that.
jkoritzinsky commentedon Aug 9, 2023
Opened microsoft/WindowsAppSDK#3783.