Enhance Microsoft.AspNetCore.Components.WebAssembly.MultipartBundle package to define a custom bundle format

[danroth27]

We've built Microsoft.AspNetCore.Components.WebAssembly.MultipartBundle as an experimental way to alter the packaging of Blazor WebAssembly apps so they work in environments that block the download of DLLs. We should consider if we want to release a stable and supported version of this package. Before we do so, we should verify that this packaging strategy is successful in these restrictive environments.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[Andrzej-W]

I think there are a lot of people who would like to develop applications in Blazor. At the same time many of them do not know that Blazor application can be blocked by a firewall and this can be an unpleasant surprise for them. In my opinion a solution like MultipartBoundle have to be supported by ASP.NET team and included in default Blazor templates.

[danroth27]

@Andrzej-W Have you tried out the experimental multipart bundle functionality and does it enable Blazor WebAssembly app execution in environments were you were previously blocked?

[Andrzej-W]

Unfortunately my Blazor app is not ready yet, it is not published and I don't have personal experience with firewalls blocking Blazor app. The app is intended for a wide audience and I must do my best to make it accessible to everyone. I hope MultipartBoundle will be an effective solution to the firewall/antivirus problem.

Perhaps you should add to the JavaScript code responsible for loading this bundle the ability to signal problems by calling the configured URL. It would be useful for monitoring the scale of the problem. It is always possible that the proposed solution will work now and after a few days/weeks/months firewall vendors will discover it and the problem suddenly returns. This function should also be able to show an error message to the user, something similar to already available "blazor-error-ui", but of course it should be a different <div> with different message.

[smartprogrammer93]

I did take a look at the approuch suggested in the blog post recently published and it seams rather complex. I believe a feature like this should be enabled by a matter of adding a nuget package to the project and adding a value to the csproject file to tell the build process to do the needful.

[petertiedemann]

@smartprogrammer93 I agree. I would like to do prototypes of offloading certain calculations to the client of our services by using WASM (combined with existing JS front-end code). Using .NET WASM is already something that makes front-end developers worried, and stuff like this just makes it impossible to even consider.

[rmencia-isv]

I did take a look at the approuch suggested in the blog post recently published and it seams rather complex. I believe a feature like this should be enabled by a matter of adding a nuget package to the project and adding a value to the csproject file to tell the build process to do the needful.

I totally agree. A default way to make the applications work in all scenarios is a must.
If the applications generated in Blazor can be blocked by a proxy in a number of scenarios, then it should be implemented by default when built in Release by adding a checkbox in VS for the project.

Also, there is the issue of static web sites, in where there is no code running in the server, so the build should already do everything that is required to create the files in the final form.

What about AOT compilation? Does this process generate wasm files of the libraries that would not be blocked?

If MS had built Office Web running in Blazor webassembly, all this would be already up and running from day 1 because otherwise it would be blocked in most companies. Maybe you could work with one of the MS Teams and build something enterprise inhouse. That would give you a better understanding or the real issues not only during deploying but also bugs in the pre-release versions. Inhouse collaboration would allow you to have access to the source code also and debug issues early.

[danroth27]

@smartprogrammer93 @petertiedemann @rmencia-isv Are any of you currently operating apps in environments where the download of Blazor WebAssembly apps is currently blocked? If yes, could you please try out the Microsoft.AspNetCore.Components.WebAssembly.MultipartBundle package and let us know if it enables Blazor WebAssembly deployment in those problematic environments? Before we make a feature like this as part of the framework, we want to collect data from customers on whether it actually solves the problem.

[peterblazejewicz]

I think question was to @petertiedemann (but yes, I work for a company where topics here can apply as valid scenario)

[rmencia-isv]

Our app is in development now and still few months away. Also my app is designed to be a static web site calling APIs. Not sure how this solution would work either. I'm in the education industry and our users will be part of schools and large universities. They are not tech savvy and every issue is a nightmare. We had heaps of issues with them blocking notification emails and I wasted weeks dealing with them to whitelist our app email. I can't even begin to imagine what it would be having to deal with reconfiguration of their proxies. I came across this issue by chance because I've created a number of issues of vs2022 and the latest update broke my blazor project due to my solution using a shared blazor library and I went to see the status and by chance I saw this issue inside 28 pages of issues. I can't imagine how many people have no idea about this and after they release the app it doesn't work and need to spend days or weeks to find a solution. Some of the architects may even get fired. I much rather change technology all together or use Blazor server, as it's too risky. And really, it makes me nervous that you don't have real applications in MS using Blazor webassembly and collaborate with them to get early feedback.

[danroth27]

@rmarinho We agree that this issue of Blazor WebAssembly apps getting blocked in certain environments is concerning, which is why we're exploring alternative packaging approaches. Please note though that it's not all environments that have this problem - it's specifically environments that block the download of DLLs. Many deployments of Blazor WebAssembly never hit this issue.

The request here is for folks that are deploying to these more restrictive environments to try out the Microsoft.AspNetCore.Components.WebAssembly.MultipartBundle package and let us know if this alternative packaging strategy enables Blazor WebAssembly usage.

[petertiedemann]

@danroth27 Our own network is not restricted in such a way, but we are a software company developing software for large industrial enterprises, and I would not be surprised to see them doing this kind of blocking.

[danroth27]

@petertiedemann Makes sense. We should have enough extensibility in place now that it should be possible to customize packaging to work for specific environments. Whether we can provide a generic solution that will work in all environments is what we're investigating with the multipart bundle package.

[rmencia-isv]

Please don't forget about static Blazor web sites when you think about that solution.

[JohnGoldsmith]

@danroth27 are you able to give more details about what “Some environments block…” means in terms of how wide the problem is and what those environments are likely to be (ie is it Enterprise only, Government and Defence etc)?

Also how would you know if you did hit this - is there a specific error code?

[danroth27]

Hi @JohnGoldsmith. We've seen users report that some firewalls are setup to block the download of all Windows PE files. The files simply fail to get downloaded. We think this is only impact a small subset of users, not the majority, but enough users reported it that we are exploring ways to address the problem. Sometimes users can work with their IT departments to remove the restriction for their apps. When this isn't feasible, users can repackage the app with different files name extensions, which we provide instructions on how to do. In other cases the inspection of the files is deeper, so we added extensibility in .NET 6 to enable further customization of the app packaging. These extensibility points give users the flexibility to adapt to the requirements of specific environments. We're also exploring multipart bundling as a generic solution, and we're looking for verification from users that are currently blocked that this approach works for them.

[JohnGoldsmith]

@danroth27 that's good to know -thank you very much for the detailed explanation. It's also good to know that there's a way out if it does raises it's head (for me).

Thanks again.

[CoryKoehler]

This may be a dumb question but why are the .dlls from blazor apps not being turned into .wasm files?

[danroth27]

@CoryKoehler They are. But the DLLs are still needed currently for certain code paths and for their metadata.

[danleydmello]

@danroth27 , willl this solution work for Static Blazor web app ? where there is no server to handle app.bundle

[danroth27]

Hi @danleydmello. I believe this solution works for static sites as long as the site host gives you a way to setup the mime type mapping for the custom .bundle extension. For example, I think Azure Static Web Apps lets you do this. GitHub Page I think doesn't.

[jez9999]

I'd like to be able to compile a WASM Blazor app using AOT into pure .wasm files, with no .dll or .bin downloads. It should then be possible to split these .wasm files into chunks much like a JS SPA app would be. I'd like Blazor to get to a stage where my app is served in several chunks (each a .wasm file with DLL code obfuscated enough to get past firewalls), where you have the chunks split up intelligently for optimal caching. For instance, one chunk could just contain commonly-used DLL code that is likely not to change, such as System.Collections.Generic. Another could contain other .NET framework dependencies for the app. Another could contain Nuget package dependencies, and another could contain the remaining app code (most likely to need regular updates).

[nbiada]

Hi all,
we have encountered a big big problem inside some big clients.
The problem are the DLLs that are blocked from AV and Firewall.
Using the AntivirsuProtection the situation sounds better but the heuristics engine of some protection systems (TrendMicro for example) block the loading phase in any case.
Switching to the BROTLI compression the situation goes better and we have less problem with the majority of the AV, but when the XDR /SIEM artificial intelligence modules come in action some xxx.dll.br are still blocked.

In the image above you can see that only 2 DLLs are blocked.
All the DLLs are compressed with BROTLI and only these two are blocked.
This is related to the heuristics engine that take in action and block these elements as suspected .
Due to the complexity of the big clients security offices, we cannot obtain special permission for public websites developed with Blazor.

Actually we're switching to propose a double options: a ligther solution on Razor Pages and Alpine JS and the actual powerful solution with Blazor WASM.

[danroth27]

@nbiada Did you try using https://github.com/stavroskasidis/BlazorWasmAntivirusProtection to package the Blazor WebAssembly app to avoid these false positives?

[jez9999]

@nbiada Did you try using https://github.com/stavroskasidis/BlazorWasmAntivirusProtection to package the Blazor WebAssembly app to avoid these false positives?

How come that doesn't bundle stuff up into one (or just a few) files?

[nbiada]

As mentioned in the post we have already tried the BlazorWasmAntivirusProtection but the AV/FW engines block the files.

[paulguz-datapa]

BlazorWasmAntivirus' author @stavroskasidis will be interested to know about the problems experienced by @nbiada. @nbiada, you may wish to raise the issue at https://github.com/stavroskasidis/BlazorWasmAntivirusProtection

I'm surprised that .Net 7 is days away and there is no official MS solution to this problem.

[danroth27]

@nbiada Please raise this issue with the relevant antivirus vendors. We've had some success with other vendors improving their detection logic to avoid these false positives.

[danroth27]

I'm surprised that .Net 7 is days away and there is no official MS solution to this problem.

@paulguz-datapa We think we're going to need to experiment with alternative formats for .NET assemblies to fully deal with this problem, which was too risky to introduce for .NET 7. We will be working to address this in .NET 8.

[stavroskasidis]

Hi all, we have encountered a big big problem inside some big clients. The problem are the DLLs that are blocked from AV and Firewall. Using the AntivirsuProtection the situation sounds better but the heuristics engine of some protection systems (TrendMicro for example) block the loading phase in any case. Switching to the BROTLI compression the situation goes better and we have less problem with the majority of the AV, but when the XDR /SIEM artificial intelligence modules come in action some xxx.dll.br are still blocked.

In the image above you can see that only 2 DLLs are blocked. All the DLLs are compressed with BROTLI and only these two are blocked. This is related to the heuristics engine that take in action and block these elements as suspected . Due to the complexity of the big clients security offices, we cannot obtain special permission for public websites developed with Blazor.

Actually we're switching to propose a double options: a ligther solution on Razor Pages and Alpine JS and the actual powerful solution with Blazor WASM.

From your screenshot I am seeing .dll files. If you are using BlazorWasmAntivirusProtection the default behavior is to rename .dlls to .bin. That means that either you did not properly configure the Antivirus protection or you disabled its dll renaming. Try it again with dll renaming and full obfuscation (default settings) to see if it helps.

[fdonnet]

Same kind of issue with zscaller corporate proxy even with BlazorWasmAntivirusProtection (bin conversion), the _framework files blocked. Issue open on the repo. Sad because the dev of the app was a blast with Blazor. Cannot have access to the policies or proxy config ... works well elsewhere. I will try to choose other file extensions (tested with bin) but with no real hope.

[fdonnet]

Issue solved with BlazorWasmAntivirusProtection (.dat conversion)... this package deserves a lot of love.

[danroth27]

Looks like Uno has done some work in this space as well that we should look at and consider: https://github.com/unoplatform/Uno.Wasm.Bootstrap/blob/main/doc/features-obfsucation.md

[danroth27]

Related .NET runtime effort: Bundle assemblies as WebCIL

[danroth27]

In .NET 8 we expect to address issues with environments blocking the download of DLLs with the new Webcil format instead of multipart bundling. The related work is being tracked by dotnet/runtime#80807. Since we expect Webcil to be a more complete soluiton and we no longer expect to ship support for multipart bunding, I'm going to go ahead and close this issue in favor of dotnet/runtime#80807. Thank you everyone who contributed feedback to help us address this issue!