This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(192, 55.00000000000001%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMJ%3C/text%3E%3C/svg%3E)
When publishing standard Blazor WASM which would be provided via Blazor server, how can I omit all references currently already available on my MAUI client? As I hope to reduce size of downloaded WASM when I am using .NET emulating within BlazorWebView, not standard browser. I want to achieve online available WASM modules by purchase available for MAUI client already containing the majority of necessary references.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(316.8, 40%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EYL%3C/text%3E%3C/svg%3E)
Do you need to separate WASM from .Net Core?
If yes, then this is not feasible at this time, as detailed in Separate The .NET Core to WASM Experience from Blazor #16021.
If no, could you please provide details about your expected behavior, the actual behavior of the program at present, and what are the differences between them?
No, all I want is to prepare MAUI client in such a way, that it would already contain all necessary references, so that all my WASM can be shrank from such references. Even if it cannot be done directly, I would like to cache such references from some dummy WASM for an example. I want only MAUI targeted WASM with C# to client C# interop for native functions. So I almost want WASM distributed with MAUI client, but I want to manage licences and access via distributing shrank WASM from the server. So, I still want to distribute my WASM's from Blazor server, but them to be prepared only for my MAUI client with cut anything I can prepare in this client, so that my users can have much smaller binaries downloaded ...
This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(211.20000000000002, 61%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBS%3C/text%3E%3C/svg%3E)
This won’t work. when hosting Blazor, Maui uses the webviews WASM support, so the WASM dlls are all required. Normally the dlls are hosted as Maui asset files, so they are loaded locally.
Even if the Maui app and the Blazor app use the same .net dll, there two versions, one compiled to native os (for Maui) and one compiled to WASM (which is a virtual machine with its own instruct set based on asm.js)
I mean MAUI with BlazorWebView. As I've studied, references from one WASM can be cached within BlazorWebView for another, so I hoped to at least cache references with first dummy WASM and omit them in the rest ... I just want to take as much advantages from targeting WASM to MAUI as possible ...
The dlls can be cached in local storage by the service worker, (but there is not much benefit as the dlls are local anyway with Maui). You can not remove the references, as the blazor code needs the references to access and to load the dlls. each webview instance has its own WASM engine. The WASM is cleared (think rebooted) on any page load, so no WASM data is shared between Blazor app loads. Any load of the Blazor hosting page causes loading of all the Blazor dlls.
If you have Blazor webviews active at the same time, they each have their own WASM with all the dlls loaded.
Yes, you're correct. Blazor WebAssembly (WASM) applications have the capability to dynamically download additional assemblies from a Blazor server, which can help reduce the initial loading time and size of the application.> When a Blazor WebAssembly application is initially loaded in the browser, it only includes the minimal runtime and framework components necessary to bootstrap the application. However, additional application logic and dependencies can be dynamically loaded from the server as needed during runtime.> This dynamic loading mechanism is typically achieved using Blazor's built-in capabilities for lazy loading of components and assemblies. By splitting your application into smaller components or feature modules, you can defer the loading of non-essential parts of the application until they are required, reducing the initial payload size and improving the overall performance of the application.> Furthermore, Blazor applications can take advantage of .NET's assembly loading capabilities to dynamically load additional assemblies from a server or CDN (Content Delivery Network) as needed. This can be particularly useful for loading shared libraries, third-party dependencies, or application-specific modules on-demand, further reducing the initial load time and optimizing the application's resource utilization.> Overall, the ability to dynamically download additional assemblies in a Blazor WebAssembly application offers flexibility and scalability, allowing developers to build efficient and responsive applications that can adapt to varying runtime requirements and constraints.
That is, what I want to achieve ... But instead from Blazor server, I want to host as much Assemblies within MAUI as possible, to reduce downloaded WASM.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(163.2, 43%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERM%3C/text%3E%3C/svg%3E)
I've gain some answers finally. The solution should be Assembly injection within DI. So, I can develop WASM referencing other DLL that I only inject with Dependency Injection, so then I would use service registered in MAUI to pass bytes of local client Assembly into WASM. And reference on Blazor WASM can be conditional, so it would be used only on Blazor server, but omitted on MAUI client. That is, what I am looking for ...
remember a WASM can not directly load a dll. The JavaScript on the hosting page loads the dll, triggered either from the manifest or a jsinterop call. Access to dlls is limited by where the hosting page is loaded from.
If the page hosting the WASM is loaded from the Maui asset folder (default for hybrid), then the JavaScript has access to the asset folder (where by default all the required assemblies are located), and are local requests.
If the Maui app loads the hosting page from a server, then access to the assets folder is blocked and all the requests are to the hosting server. The Maui app code could monitor the webview url requests, and override their response.
DLL can be passed from MAUI to WASM by interop - as byte array. JS can pass bytes to WASM's C# and then it can be dynamically loaded as Assembly ... This should be sufficient to manage Lazy load and reduce initial WASM's size ...
I just not sure your use case. It appears your just reinventing Blazor’s lazy loading.
Almost. The difference is, that I not want Blazor server resolver. I do not want to download omitted references online. I have them already in my MAUI client. So that was the question. And I already developed and described the solution here ...
Finally, it is working!
Answer is very easy. I can deploy WASM with conditional references, so they will be omitted in deployed WASM. I can leak .NET object from WASM into JS. JS can leak unmarshalled object into MAUI client. MAUI client can provide any of its loaded assembly as a byte array for unmarshalled WASM object. WASM can use those bytes to dynamically load any omitted assembly. That is how to shrank WASM when I have direct control on client side to still provide working WASM at the end.