[Kryptos-FR]

PR Details

Use the same crash report mechanism for the Launcher.

This avoid a unstable workaround in the Launcher that tricked the Avalonia runtime to start a new app. It did not work in every cases and could be broken in any future update as it's not officially supported.

Relates to #3348.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the launcher to try this change out.

[Kryptos-FR]

@xen2 I think the trigger for the Launcher CI is broken. It should have triggered but it was skipped. I believe there is a missing github.repository == 'stride3d/stride' condition. Compare with the condition in main.yml.

[xen2]

@xen2 I think the trigger for the Launcher CI is broken. It should have triggered but it was skipped. I believe there is a missing github.repository == 'stride3d/stride' condition. Compare with the condition in main.yml.

Good catch, can you try again? (a rebase should suffice)

[xen2]

Trying to use same out of process system will need a lot of extra work & testing:

• Packaging & locator: where does it end up? inside the self-contained published Stride.exe? or side-by-side? I don't think your PR take care of that part (the exe won't be in the nupkg).
• Crash reporter adds a dependency on .NET 10 unless we also self-contain publish it (which will add 30~100MB extra on existing launcher, depending on trim and/or compression)
• If we self-contain publish, we need to handle several details: how to launch it on windows/linux (i.e. not use dotnet but the apphost), signing, etc.
• If self-pack, we need one per RID. We have 4 currently (win-x64, win-arm64, osx-arm64 and linux-x64). So we're looking at 4x (150 + 30~100) = 700~1000MB! (that's a problem we'll have for the launcher anyway, we might need to look into per-RID nupkg + check trimming/compression)
• More complexity & moving pieces, testing, etc. (it works differently than Game Studio and Asset Compiler case since we're not using nuget resolver for it -- so sharing same approach doesn't help us much in this case, quite the opposite)

Overall, I feel it's not worth it, unless there's something we fundamentally can't fix for the in-process version.
Is our issue/workaround for in-process (you mentioned the need for a new Avalonia app) something we can't fix/avoid?

I was initially hoping using Avalonia crash reporter lib in Avalonia launcher would play nicely and keep things simple.

[Kryptos-FR]

I'm not sure to understand all your points.

Packaging & locator

It's the same as the GameStudio, the Launcher references the package privately which should force it to resolve with nuget. Then it calls NativeCrashReporting API which does all the resolution, including from the store.

Crash reporter adds a dependency on .NET 10

Already the case for the new Launcher. Avalonia requires .NET 10. Installing the .NET 10 runtime should be taken care of by the setup installer or added explicitly as a pre-requisite in the documentation. Tne GameStudio and the CLI also requires .NET 10, so not sure what the issue is.

[xen2]

I'm not sure to understand all your points.

Packaging & locator

It's the same as the GameStudio, the Launcher references the package privately which should force it to resolve with nuget. Then it calls NativeCrashReporting API which does all the resolution, including from the store.

GameStudio depends on CrashReporter (as a nuget dependency) so we know for sure it's restored.
Then we use the nuget resovler code to find it.

I don't think the launcher is doing any of that (and it's too late to do it when it crashes anyway)

Also there is no real "corresponding" version: CrashReporter is released with GameStudio version (i.e. 4.4.0) and is tied to its command-line interface (in case we add extra command line parameter for new crash reporting details, mode, etc.)

So we would need to do a new Stride.Launcher.CrashReporter package matching launcher version (fixed); at this point, why not simply have it inside the Stride.Launcher package?

Crash reporter adds a dependency on .NET 10

Already the case for the new Launcher. Avalonia requires .NET 10. Installing the .NET 10 runtime should be taken care of by the setup installer or added explicitly as a pre-requisite in the documentation. Tne GameStudio and the CLI also requires .NET 10, so not sure what the issue is.

No, since we do a self-contained app, it doesn't need the .NET runtime installed at all.
Our Setup.exe (Launcher) doesn't have any prerequisites at all. This is quite convenient, because it simplifies a lot of setup step (extra-UAC, self-update is simpler, no need for a packageinstall.exe in case of update to a newer framework, etc.).
Also it can't break if the user change/uninstall .NET framework, and less testing in case of roll-forward and details like this.

Of course, Stride itself have packageinstall.exe + install-prerequisites.exe to install any new prerequisites not on the system.

Or, do you mean that Avalonia doesn't support to be embedded in a self-contained app, and need the actual framework somehow?

[github-actions]

🤖 Draft PR — automatic CI is skipped to save runner minutes.

• Mark the PR ready for review to run the full automatic CI — or add a ci-run-on-draft label to run it now without leaving draft.
• Or arm a specific opt-in suite: ci-enduser, ci-editor, ci-ios, ci-android.

[Kryptos-FR]

@xen2 I will think about it. There might be some workarounds (like publishing both Strride.CrashReporter and Stride.Launcher trimmed), but right now it doesn't exactly work. I found a few other issues that can prevent publishing. I'll open a separate PR for them.