Published app silently crashes with: Bundle header version compatibility check failed.

[Symbai]

Description

Running a framework dependend, single file published wpf .NET 6.0.100-rc.1.21463.6 on a computer without .NET6 installed silently fails. But there should be a messagebox that runtime is missing. Event viewer says:

Description: A .NET application failed.
Application: WpfApp9.exe
Path: C:\Users\User\Desktop\WpfApp9.exe
Message: Failure processing application bundle.
Bundle header version compatibility check failed.
A fatal error occured while processing application bundle

Publish settings:

Configuration

.NET 6.0.100-rc.1.21463.6 (SDK, on computer which published the app through VS)
WPF
Windows 10
NO .net installed on target computer (edit: having .NET 5 x64 sdk or runtime installed doesn't help, app is still silently crashing)

Regression?

Yes, there should be a messagebox telling .NET 6 (desktop) runtime is missing.

Other information

I created a new WPF project using VS 2022 preview and instantly published.
//edit: Publishing the same app with no "single file" enabled opens the expected message box on target computer, so there is an issue with single file option:

Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Running a framework dependend, single file published wpf .NET 6.0.100-rc.1.21463.6 on a computer without ANY .NET installed silently fails. But there should be a messagebox that runtime is missing. Event viewer says:

Description: A .NET application failed.
Application: WpfApp9.exe
Path: C:\Users\User\Desktop\WpfApp9.exe
Message: Failure processing application bundle.
Bundle header version compatibility check failed.
A fatal error occured while processing application bundle

Publish settings:

Configuration

.NET 6.0.100-rc.1.21463.6 (SDK, on computer which published the app through VS)
WPF
Windows 10
NO .net installed on target computer

Regression?

Yes, there should be a messagebox telling .NET 6 (desktop) runtime is missing.

Other information

I created a new WPF project using VS 2022 preview and instantly published.

Author:	Symbai
Assignees:	-
Labels:	area-Single-File, untriaged
Milestone:	-

[agocke]

@VSadov Can you take a look and see what error path we have for this scenario?

[vitek-karas]

This is going to a bit tricky. The error in this case comes from the downlevel hostfxr (I don't know which version it is in this case, but let's say 5.0).

We do have a check for really old hostfxr, like 3.1 which didn't support the new bundles, in which case the apphost will fail with a good error and I think it should show a dialog about needing to install newer version.

But in this case, the hostfxr is aware of single-file bundles, just not the version we're trying to process. Unfortunately it doesn't fail with a specific error code. It fails with a generic BundleExtractionFailure,

For 6.0 we should consider a change to apphost. Currently it will not popup a dialog if bundle extraction fails (for any reason). We should fix that and popup a dialog. Given the existing code, we could probably read through the error output (we already do that for the dialog in other cases) and detect the case of wrong header version. And then simply treat it the same as missing framework version, but with different error message. For other bundle extraction failures, we can consider not showing the dialog - as that should not be common at all and we don't have much to say. But we could show it to improve overall UX (if we don't the app doesn't do anything visually, which is pretty bad UX).

For 7.0 we should improve this by changing the handshake between apphost/hostfxr to allow a bit more detail around errors. Either by returning new error code, or maybe even some more structural error data. So that we don't have to guess from the error messages.

[VSadov]

Yes, we should handle extraction failure with a dialog. At least for the common cases like fxr too old. It could be a common mistake.

[Symbai]

And then simply treat it the same as missing framework version, but with different error message.

What different error message are you thinking about? For me this missing runtime dialog is VERY important because its the only thing which is shown to an end user. And if this "error" is fixed by installing a specific runtime version, then the error should tell the user exactly this. There shouldn't be an error message like "Bundle extraction failed". An end user doesn't know what that means and what to do. I have no idea about the underlying technical details here but a perfect solution for this to me is to display the missing runtime error prompt as shown in screenshot in first post.

[vitek-karas]

Sorry for not making it clearer. The "different error message" note was mostly about the implementation details - currently we parse the errors generated to determine what exact framework was missing (to put it into the URL) and to construct the right message for the dialog. The same code will not work for this case, since the generated errors don't contain that information, so the host will have to compensate and generate the dialog message and URL on its own.

It will probably be better to treat it more like the "Missing runtime" failure (CoreHostLibMissingFailure) but still with some additional logic to construct the URL. I'll try to look into this today (and hopefully come up with some proposed change).

[vitek-karas]

The 6.0 backport is in this PR #60045