Net8 Support -- BlazorWorker: Unable to locate dotnetjs file in blazor boot about blazorworker HOT 10 CLOSED

This is a new breaking change in the bootstrapper. For net8 the blazorboot is reconstructed quite heavily with the runtime being split up in two files, dotnet.native.8.0.0.ot6jeefn53.js and dotnet.runtime.8.0.0.1khq4boqw1.js. I'm going to have to do some reading to solve this

from blazorworker.

await dotnet.run()
In any case this line is useless as all it does is call Program.Main() which is needed for nothing.

That is indeed just running main.

@maraf we should update our template to make it clear users don't have to call this.

Something has changed in .net8 which make this line break the runtime.

The change is that we will properly "exit" the "process" after main is finished.

from blazorworker.

Most probably related to this #85

from blazorworker.

.net8 support works in https://github.com/Tewr/BlazorWorker/releases/tag/v4.0.0-preview2 , try it out.

from blazorworker.

Yes most likely. The breaking changes of net7 are not likely to have been reverted in net 8

from blazorworker.

I've made some progress here tonight, but Crucial JsInterop fails without error
#91

from blazorworker.

Some notes on progress.

Some further investigation show that while JsInterop seems to work OK, Tasks does not seem to work correctly. I can finalize the service Init message loop without errors, as the service init function is fully synchronous. That is, I send a message to initialize a service in the worker, and the service starts, and sends a "initialized" message back to the UI thread without problems.

So the dotnet environments starts, and functions can be executed as long as they are synchronous or does not provoke an actual Task switch. If a task is force started with Task.Run, it never executed. if I attempt to await Task.Delay, the calling function seems to freeze over. The details need to be investigated further, but at a first glance the first Task which is not the main Task and thus run on the Task scheduler is stuck in WaitingForActivation status.

It is possible that there are some new defaults for the Task scheduler when starting the runtime? That makes it default to a single task when running on a worker. Some kind of different behaviour when detecting that being run in a worker. Maybe some side effect from the work that has already started on multithreading in the runtime.

from blazorworker.

I would really like this to be fixed.
Would it be possible to push a build that only supports syncronous workloads?

from blazorworker.

I haven't been able to reproduce a fully working runtime even while avoiding the triggering of a task switch. Something is missing.

The following linked issue plans to post/blog some kind of guide, might be useful but seems like they are planning for a demo using a separate template and a separate build, which is a bit sad, cause it's a lot more work

dotnet/runtime#95452

from blazorworker.

Some good news after climbing down the rabbit hole: need more investigation but await dotnet.run(); , which was introduced by me while testing .net7, seems to be the culprit.

Seems to work fine after removing this line. Something has changed in .net8 which make this line break the runtime. In any case this line is useless as all it does is call Program.Main() which is needed for nothing.

If this is really the case, I might be able to get out a beta version in a few days. I need to get some kind of basic multitargeting code in place first

from blazorworker.