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.

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.