[regression/8.0.0-preview.6] Maui app won't start when referencing EpubSharp.dll package

[DDHSchmidt]

Description

Since bugfixes are more or less abandoned for the .Net 7 branch, I started to migrate our internal app to .Net 8.

Today I installed the .Net 8 Preview 5, updated the MAUI reference to 8.0.0-preview.5.8529 in our csproj file and tried to fire it up on my windows machine using Visual Studio 17.7.0 Preview 2.0.

Deployment works fine, but immediately after that Visual Studio stops and the only thing in the debug output is
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core. The program '[19804] CompanyApp.exe' has exited with code 2147516547 (0x80008083).

This still worked fine, when I had everything running under .Net 8 Preview 4.
I also verified that a brand new Maui project, created from Visual Studio's Project template, deployed and started without issue.
That probably means there's something wrong with my setup, but I get next to nothing as info, leaving me stumped as to where I could look next?

Google led me to the conclusion that 0x80008083 stands for 'CoreHostLibMissingFailure' and that's about it :/

Steps to Reproduce

1. Install .Net 8 Preview 6 SDK
2. Raise MAUI version in csproj to 8.0.0-preview.6.8686
3. Add EpubSharp NuGet package
4. Start debugging on Windows
5. Wait for error after successful deployment

Link to public reproduction project repository

Unfortunately I can not provide this, due to this being an internal project
UPDATE: Easily reproducible by adding EpubSharp NuGet package to a new Vanilla Maui project

Version with bug

8.0.0-preview.6.8686

Last version that worked well

8.0.0-preview.4.8333

Affected platforms

Windows

Affected platform versions

Windows 10 (22H2), Maui 8.0.0-preview.5.8686

Did you find any workaround?

No, unfortunately
UPDATE: Remove EpubSharp package

Relevant log output

The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[19804] CompanyApp.exe' has exited with code 2147516547 (0x80008083).

[DDHSchmidt]

I wanted to add the only relevant search result concerning this eror led me to workarounds for .Net 7

Naturally, even trying the properties mentioned in this article led to no progress. I'm still stuck with an application that won't start, let alone debug on Windows.

[DDHSchmidt]

The problem still persists, even with Preview 6.
I tried cleaning all /obj & /bin folders and deleting and cloning my repository again and it led to no improvement.

I've been unable to debug (and in extension migrate) my solution under .Net 8 for one month now. That's pretty harsh considering everyone is pushing hard to migrate to .Net 8 :/

[DDHSchmidt]

Without any lead or advice I started playing Whack-a-mole with our dependencies, having to outcomment/remove hundreds of lines of code for every removed package.
After hours (!) I finally spotted the breaking package: EpubSharp

When I remove the reference to that package, Visual Studio has no more problems starting our app in debug mode!
As I stated earlier: There is absolutely no mention of it in the build-/debug-output and Ihave no idea how I could have found this culprit otherwise :/

It's even reproducible when you add the dependency to a new Vanilla Maui Project. I recorded a video of me adding the package and the app not being able to start anymore:

Maui_breaking_on_EpubSharp.mp4

[XamlTest]

Verified this on Visual Studio Enterprise 17.7.0 Preview 4.0. Repro on Windows 11 .NET 8, not repro on Android 13.0-API33 and iOS 16.4 with below Project:
15678.zip

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Since bugfixes are more or less abandoned for the .Net 7 branch, I started to migrate our internal app to .Net 8.

Today I installed the .Net 8 Preview 5, updated the MAUI reference to 8.0.0-preview.5.8529 in our csproj file and tried to fire it up on my windows machine using Visual Studio 17.7.0 Preview 2.0.

Deployment works fine, but immediately after that Visual Studio stops and the only thing in the debug output is
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core. The program '[19804] CompanyApp.exe' has exited with code 2147516547 (0x80008083).

This still worked fine, when I had everything running under .Net 8 Preview 4.
I also verified that a brand new Maui project, created from Visual Studio's Project template, deployed and started without issue.
That probably means there's something wrong with my setup, but I get next to nothing as info, leaving me stumped as to where I could look next?

Google led me to the conclusion that 0x80008083 stands for 'CoreHostLibMissingFailure' and that's about it :/

Steps to Reproduce

1. Install .Net 8 Preview 6 SDK
2. Raise MAUI version in csproj to 8.0.0-preview.6.8686
3. Add EpubSharp NuGet package
4. Start debugging on Windows
5. Wait for error after successful deployment

Link to public reproduction project repository

Unfortunately I can not provide this, due to this being an internal project
UPDATE: Easily reproducible by adding EpubSharp NuGet package to a new Vanilla Maui project

Version with bug

8.0.0-preview.6.8686

Last version that worked well

8.0.0-preview.4.8333

Affected platforms

Windows

Affected platform versions

Windows 10 (22H2), Maui 8.0.0-preview.5.8686

Did you find any workaround?

No, unfortunately
UPDATE: Remove EpubSharp package

Relevant log output

The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[19804] CompanyApp.exe' has exited with code 2147516547 (0x80008083).

Author:	DDHSchmidt
Assignees:	-
Labels:	area-Diagnostics-coreclr
Milestone:	-

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Since bugfixes are more or less abandoned for the .Net 7 branch, I started to migrate our internal app to .Net 8.

Today I installed the .Net 8 Preview 5, updated the MAUI reference to 8.0.0-preview.5.8529 in our csproj file and tried to fire it up on my windows machine using Visual Studio 17.7.0 Preview 2.0.

Deployment works fine, but immediately after that Visual Studio stops and the only thing in the debug output is
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core. The program '[19804] CompanyApp.exe' has exited with code 2147516547 (0x80008083).

This still worked fine, when I had everything running under .Net 8 Preview 4.
I also verified that a brand new Maui project, created from Visual Studio's Project template, deployed and started without issue.
That probably means there's something wrong with my setup, but I get next to nothing as info, leaving me stumped as to where I could look next?

Google led me to the conclusion that 0x80008083 stands for 'CoreHostLibMissingFailure' and that's about it :/

Steps to Reproduce

1. Install .Net 8 Preview 6 SDK
2. Raise MAUI version in csproj to 8.0.0-preview.6.8686
3. Add EpubSharp NuGet package
4. Start debugging on Windows
5. Wait for error after successful deployment

Link to public reproduction project repository

Unfortunately I can not provide this, due to this being an internal project
UPDATE: Easily reproducible by adding EpubSharp NuGet package to a new Vanilla Maui project

Version with bug

8.0.0-preview.6.8686

Last version that worked well

8.0.0-preview.4.8333

Affected platforms

Windows

Affected platform versions

Windows 10 (22H2), Maui 8.0.0-preview.5.8686

Did you find any workaround?

No, unfortunately
UPDATE: Remove EpubSharp package

Relevant log output

The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[19804] CompanyApp.exe' has exited with code 2147516547 (0x80008083).

Author:	DDHSchmidt
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	9.0.0

[hoyosjs]

The problem here lies somewhere between the package, SDKs, and maui's projects. Starting the project with release config and no debugger still fails to start up the app. As part of this I've also ruled out a regression caused by the RID graph. That package defines netcoreapp1.1 and netstandard1.3 dependencies that tend to bring a lot of the old packages and with them all the woes from said times. Particularly, the 1.1.1 dependency of the reference brought in a ref to the old host policy packages and build ends up copying dotnet.exe, hostfxr.dll, and hostpolicy.dll to the output. The main difference is in p4 sdk copies the p4 runtime - akin to a publish, so host FXR and policy and newer ones and load the runtime as if it was a self contained publish. On p7 assets get copied such that the FXR that gets deployed is from 2016 and no runtime is copied. Their presence makes the runtime fail to start up. This is at best a compat regression WRT published assets done as an explicit decision in the work on the SDK, and definitely is something that will make referencing really old packages really hard in 8.0. @marcpopMSFT I'm transferring this to SDK since this is a change in the behavior of dotnet build, not sure if this is a known consequence of the work done in build/publish. cc @richlander cc @elinor-fung and @vitek-karas since I guess this won't be the last we'll see of this bug.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[elinor-fung]

The main difference is in p4 sdk copies the p4 runtime - akin to a publish, so host FXR and policy and newer ones and load the runtime as if it was a self contained publish. On p7 assets get copied such that the FXR that gets deployed is from 2016 and no runtime is copied.

Could this be related to https://learn.microsoft.com/dotnet/core/compatibility/sdk/8.0/runtimespecific-app-default? Maybe the app is assuming setting RuntimeIdentifier would make it a self-contained deployment? cc @baronfel @nagilson

[baronfel]

That was the first thing that came to my mind @elinor-fung. The correct flag for determining if a private runtime will be present is SelfContained, is this project set to build in that mode, or is there a reasonable assumption that SelfContained is required for this kind of app that could be enforced in its targets?

[vitek-karas]

UPDATE: Easily reproducible by adding EpubSharp NuGet package to a new Vanilla Maui project

Based on that I would assume it's not the self-contained on/off problem - unless Maui template project is setup incorrectly (which is unlikely). I've seen this before on an internal case.

The problem is that the 1.1 package will have a dependency on lot of the host packages (just like Juan mentions above) and "modern" SDK doesn't recognize these old host packages as "part of the framework" and won't remove them from the output. So the app is left with a really old host libraries in its output. Depending on the exact way of running the app and other stuff, the host will get confused by this and think it's a self-contained app when its' not, or the really old hosting components won't work with modern runtime. It's basically a broken state when that happens.

I didn't try to repro this, so I don't know which exact case this hits. In the other case where we ran into this we recommended updating the old package to target at least netstandard2.0. But as Juan mentions, this might not be possible for some packages which the developer has no control over and which are not maintained anymore. For example, the package EpubSharp has been last updated in 2011, so 12 years ago.

@dsplaisted I think you were on the internal discussion over a similar issue.

It think, that what we need to figure out is "What changed recently?". We're very unlikely to fix the actual problem here (SDK recognizing old host packages as part of the framework), but if we can maybe revert to the way we did things before without hurting anything...
Otherwise, if that's not possible (or not worth it), we should make this into a documented breaking change.

[DDHSchmidt]

I can confirm that EPubSharp doesn't obstruct my MauiBuild anymore.
I downloaded the sources, placed them in a private NuGet Repository, updated the EPubSharp sources to target .Net 7, released another artifact, imported that into my Maui project et voilà: Builds & starts.

That sounded easy, but incorporating private Nuget feeds into an Azure pipeline always is a shitty experience, albeit outside the scope of this issue.

But yeah: Having a big, fat warning in the documentation about this should be the minimum. Even better: A big fat warning in the build output that directs you to said documentation.
The worst part about this was playing whack-a-mole with the dependencies for hours until I figured out which package influenced this.
Such a waste of time...

Also: That solution can't be applied to old dependencies based on closed-source packages.

[dsplaisted]

This sounds somewhat similar to #3044. It's possible that the same workaround would work, namely:

<PackageReference Include="Microsoft.NETCore.Targets" Version="2.1.0" ExcludeAssets="all" PrivateAssets="all" />

[DDHSchmidt]

This sounds somewhat similar to #3044. It's possible that the same workaround would work, namely:

<PackageReference Include="Microsoft.NETCore.Targets" Version="2.1.0" ExcludeAssets="all" PrivateAssets="all" />

This does not seem to help in this particular case. When referencing EpubSharp's official version from NuGet.org and including that line, the exact same error happens as outlined in the first post.

[dsplaisted]

@jonathanpeppers @Redth Is Maui switching to using portable RuntimeIdentifiers, ie using win-x64 instead of win10-x64? I did a bit of experimentation and it looks like that would fix this issue, as the offending assets such as hostfxr are coming from packages using win7-x64 as the RuntimeIdentifier, so they wouldn't be included when using the portable win-x64 RuntimeIdentifier.

[jonathanpeppers]

@mattleibow do you know the status of moving from win10-x64 -> win-x64?

MAUI might be blocked on WindowsAppSdk moving first?

[baronfel]

@jonathanpeppers we're getting late in the cycle and the knock-on effects of the portable RID graph change seem to be pretty bad here - should MAUI projects default to setting the MSBuild property to revert to the full RID graph?

[jonathanpeppers]

They are doing this on Windows already:

https://github.com/dotnet/maui/blob/6aac924e89bbe5f92548d5f7d6c962f9336943ed/src/Workload/Microsoft.Maui.Sdk/Sdk/Microsoft.Maui.Sdk.Before.targets#L8-L9

It looks like this has been here since .NET 8 Preview 7.

[vitek-karas]

Is there an issue tracking the removal of that? I understand that for .NET 8 (maybe), but we should really push to get rid of the dependency on the full RID graph. There are no plans to update that graph going forward - and we would really like to get rid of it completely soon.

/cc @agocke @elinor-fung

[jonathanpeppers]

@mattleibow do we have a work item somewhere for the WindowsAppSdk team? They may not use GitHub for tracking work.

[mattleibow]

The WASDK team does use GitHub, just ping me and I can add some maui labels to make sure they get it prioritized.

However, they mentioned they are unable to do the win10 to win for the 1.4.x versions, so will have to wait for 1.5.x. So for now, we will have to set the UseRidGraph as we are for the foreseeable future.

However, we also need to wait for Win2D to update as we also depend on them.

[vitek-karas]

Do we have an issue on the MAUI side to track this and hopefully remove this next release?

[marcpopMSFT]

@mattleibow @jonathanpeppers if ya'll create a maui tracking issue to track the dependencies updating to the new RID graph, can we close this issue?