Release Builds don't Works

[marcussacana]

My program run fine in debug build, but when I build as Release, I got a Method not found error (WebAssembly.Runtime:GetDateValue)

First I didn't know from where this happen, but after take a look the WebAssembly.Runtime is from the WebAssembly.Bindings; and this is one of the dependencies of the BlazorWorker.WorkerCore;
And then, i'm here now :)

This probabbly isn't your fault, but I really don't know what I do now...

[Tewr]

I've seen this error a few times, it's almost always due to either build or browser cache. Close visual studio, Manually delete bin and obj folders, and empty all browser caches. If you are running the pwa template with service worker, emptying the cahces might be extra tricky. Let me know if this helps.

[marcussacana]

Nahh, I already did that, in the true I even created a new blazor project and copied only the .razor/.cs files, but nothing worked...
But don't care, I forgot to comment but I managed someway...
Basically, I re-implemented the DOMObject using a means independent of WebAssembly.Runtime to invoke javascript, After removing the dependency on that library everything is working.

[Tewr]

Ok thanks.

Could you share your workaround in the meantime?

[marcussacana]

Here, it's the BlazorWorker with all changes that I did
https://github.com/marcussacana/Sermone/tree/b9f003a01adcc52f39b4a80f930252c8c170168e/Dependencies

[marcussacana]

More detailed my changes are in the files:

The Eval script in the BlazorWorker.js is the Microsoft.JSInterop Javascript
https://github.com/marcussacana/Sermone/blob/b9f003a01adcc52f39b4a80f930252c8c170168e/Dependencies/BlazorWorker/BlazorWorker.js#L13-L16

My DOMObject implementation (the main part of the workaround)
https://github.com/marcussacana/Sermone/blob/b9f003a01adcc52f39b4a80f930252c8c170168e/Dependencies/BlazorWorker.WorkerCore/DOMObject.cs#L11-L24

New Dependencies Required due the workaround
https://github.com/marcussacana/Sermone/blob/b9f003a01adcc52f39b4a80f930252c8c170168e/Dependencies/BlazorWorker/WorkerProxy.cs#L61-L69

This change isn't related with the workaround, I just wanted include custom libraries in my worker thread.
https://github.com/marcussacana/Sermone/blob/b9f003a01adcc52f39b4a80f930252c8c170168e/Dependencies/BlazorWorker/WorkerProxy.cs#L12

[Tewr]

Thanks, that will give me some ideas for a fix!

Regarding the last comment, you can include custom libraries using WorkerInitOptions.DependentAssemblyFilenames. these parts are not very well documented yet...

[marcussacana]

Ohh, good to know, thx, also, I think probabbly this error is something related to the Blazor linker, and probabbly can be solved by excluding that assembly of the linker optimization...
I found this doc, If you can't reproduce this bug, I can test here to you
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/blazor/configure-linker?view=aspnetcore-3.1

[Tewr]

I can reproduce, thats why I flagged the bug. But it worked when I published the package, a bit weird

[Tewr]

I've had the time to look a tiny bit, I've actually had this error in a previous version of blazor. Back then the solution was similar - the problem seemed to be to directly depend on webassembly.bindings. there is probably a conflict of namespaces, that only manifests when running the linker. A few months ago it manifested all the time.

Back then I used some byte trickery so load a different dll than the one requested by the runtime... That could be part of the solution. I'm going to have to compare the memory footprint/load time to see what to do here, (use blazor dlls like you did, or continue to use webassembly.bindings) there is also the issue of the interop classes mostly being non public in the blazor way of interoping... so there is also the issue of maintainability, loading blazor internals with reflection has turned out to be quite fragile in the past.

[marcussacana]

Well, as usuall, reflection isn't good ¯\_(ツ)_/¯
Hmmm, isn't possible create a new AppDomain to load the worker sandboxed then..?
--edit
Nahh, maybe not... the blazor envoriment will reload the library anyway...?
--edit
hmm, thinking more maybe you can create a AssemblyResolver handler to prevent the WebAssembly.Bindings being loded 2 times?

[Tewr]

I could probably fix this by creating a new intermediary assembly. The problem is that blazor, running on the main thread, knows about blazor workercore, where as is doesn't really have to. On the other hand, if it doesn't, the dlls won't be brought when building, so they have to be brought manually somehow. I could do this with custom msbuild steps but I have too little experience with this. But the linker step complicates this. The trick is to find a good compromise I guess, without creating an unmaintainable spaghetti...

[Tewr]

The strategy I'm going to try first when I get my hands on a computer is to remove the dependency to webassebly.bindings, embed the dependency in blazorworker.workercore as a resource, and then load it using reflection.

[Tewr]

When compiling in Release mode with linker activated, the linker gets a bit confused as WebAssembly Runtime exists both in Blazor and WebAssembly.Bindings.

Preserving WebAssembly.Bindings from the linker wont help this. it will actually make the problem if not worse, then more explicit. However, removing WebAssembly.Bindings from the eyes of the linker seems to to the trick..

[Tewr]

This fix will be included in the next release. As 3.2 is out of release candidate while I did this, I probably wont do an explicit release though, it will be the same as the release targeting 3.2 final.

[marcussacana]

Okay, thank you, I will take a look soon, because i'm working in another thing now.
If everything works I will close the issue.

[Tewr]

This is in release 1.2.1, package is published.

[marcussacana]

Tested, Everything working, thank you :)