Load Javascript file from EmbeddedResource in WasmBrowser?

[SerratedSharp]

If I have a WASM project(WASM Browser tempalte from wasm-expiremental workload) referencing another class library project or nuget package that will be compiled into the WASM project,. Is there a way for the class library project to emit its javascript declarations it depends on, or for ImportAsync to reference an embedded file?

Currently I use Uno's invokeJS passing the entire embedded script content to emit the declarations that my JSImport's depend on: WebAssemblyRuntime.InvokeJS(EmbeddedFiles.JSInteropProxies); and the class library emits its own dependencies. I imagine an eval()-esque invoke async was omitted from JavascriptServices since it can be dangerous for non-static content.

[maraf]

Have you considered using "Razor classlib"? It doesn't have to contain any razor files, but it works well with the WebAssembly SDK.

[SerratedSharp]

I got the staticwebassets using RCL to work, but as far as I can tell(based on browser network tab), JSHost.ImportAsync retrieves them from the server. So it works only because the server understands how to resolve the request server side and pull it out of the library that is also server side.

JSHost.ImportAsync("SerratedJQ", "/_content/SerratedSharp.SerratedJQ/SerratedJQ.js");

Is there something I'm missing? Is there a way to instruct JSHost.ImportAsync to resolve client side, since the needed file is embedded in the WASM module? Something analogous to a client side HTTP interceptor.

Otherwise if this is as designed I'll open a request to see if we can get an overload of ImportAsync that references client side files embedded in the WASM. I.e. a traditional server that includes a client side WASM module won't necessarily understand how to resolve requests server side for the embedded RCL scripts. My prior approach is agnostic of the server host:

[maraf]

a traditional server that includes a client side WASM module won't necessarily understand how to resolve requests server side for the embedded RCL scripts

Static Web Assets understands nuget packages produced by razorclasslib and copies _content/* files to the output wwwroot folder. It works in a smarter way that it does the copy only during publish, during build it references the files from nuget cache so they are not needed to be copied. So during build you need a slightly smarter HTTP server (like the used by dotnet run, but when you publish / production build, you can use any web server that is able to serve static files.

Is there a way to instruct JSHost.ImportAsync to resolve client side, since the needed file is embedded in the WASM module?

No, there is not. I don't see the benefit here. What is the motivation for you to embed scripts in the dll?

[SerratedSharp]

it does the copy only during publish, during build it references the files from nuget cache so they are not needed to be copied

That makes sense, thank you. Is publish expected to work for wasm-browser template currently? I tried folder publish with a freshly created project and it doesn't do anything. It says it succeeded, but nothing showss being copied/generated in output, and the folder doesn't exist:

What is the motivation for you to embed scripts in the dll?

Makes the WASM more self contained since it can include the WASM code and it's own JS shims the code depends on. Simplifies consumer's setup. Initial setup/config is always where consuming a new package can be frustrating, because every additional step for the dev to perform is a potential place to make an error. The package can control when the declarations are created and there's no potential URL resolution issues since you don't need to make a request for the scripts.

[maraf]

Is publish expected to work for wasm-browser template currently?

These is an issue about publish location, tracked in #99159. Is it also your case?

Makes the WASM more self contained since it can include the WASM code and it's own JS shims the code depends on.

Do you see Static Web Assets approach sufficient? It includes scripts in the package, extract them to a conventional URL, so no server logic is needed and scripts don't collide

[SerratedSharp]

I had read on it, and wasn't sure how specific it was. I will try that thanks.

…

On Thu, Mar 14, 2024, 7:52 AM Marek Fišera ***@***.***> wrote: Have you considered using "Razor classlib"? It doesn't have to contain any razor files, but it works well with the WebAssembly SDK. — Reply to this email directly, view it on GitHub <#99746 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXFH3LDIC7AQ5ISYWVH4U3TYYGFQNAVCNFSM6AAAAABEVORFC2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DOOBVGI2TC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[SerratedSharp]

These is an issue about publish location, tracked in #99159. Is it also your case?

I searched from the solution root and there were no publish folders(I checked specifically the location you mention in your issue as well).

Clicking Publish in the profile UI doesn't do anything other than output this to built output:

Build started at 7:36 PM...
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Build completed at 7:36 PM and took 00.039 seconds ==========

I tried running dotnet publish command from nuget console(intending to turn on verbose output) referencing the publish profile name, there was definitely more activity, and I saw the publish folders get created(created an empty publish folder in correct location, and populated another publish folder in the "wrong" location consistent with your issue.). I deleted publish folders, and retried the Publish button in UI, still nothing happened. Ran command again and it works. So seems somehow specific to the UI. I have a workaround at least.

I also notice the oddity that Target runtime is initially set to Portable in publish profile UI, which matches your screen shot in linked issue, but if I click edit it changes to browser-wasm, and there is no portable option in that drop down. Doesn't have any impact on whether it works or not though. Do you observe this UI oddity as well?

Do you see Static Web Assets approach sufficient? It includes scripts in the package, extract them to a conventional URL, so no server logic is needed and scripts don't collide

It is sufficient, thanks.

[maraf]

Can you please share a binlog from the publish in VS? Here are instructions https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Providing-Binary-Logs.md#capturing-binary-logs-through-visual-studio. The folder will contain quite some files, I'm interested in those CentralNode_dotnet_PID=*_BuildManager_Default.binlog, probably the largest one.

[SerratedSharp]

I setup environment and ran, once loaded I did a Publish from UI, then closed VS. Here is the binlog produced:
CentralNode_devenv_PID=21732_x64_BuildManager_Default.zip

This is the solution minus the bin/obj folders:
WasmBrowser2.zip

[SerratedSharp]

@maraf Pinging you on the above binlog I added regarding the Publish UI button not working.

Also, I found another issue that occurs whenever a wasmbrowser project references a RCL project where the RCL name is alphabetically before the wasmbrowser name, and it breaks the dev server: https://www.youtube.com/watch?v=IfXlfRssbXc

I created an issue for the project naming bug which included system logs and added a MS Only comment with VS binlogs for this seperate issue uploaded, and a video was also attached to the ticket: https://developercommunity.visualstudio.com/t/WasmBrowser-and-RCL-projects-fail-based-/10627677

Let me know if it is appropriate to create a github issue for either of these.

[maraf]

I'm sorry for late reply.

Thank you for infomation. I'll investigate both issues

[maraf]

I have opened a #100631 for the RCL problem.
The publish from VS problem is more deep, I'll expand the already mentioned issue for that.
Thank you!