Blazor WASM Packager

Update log

• 2025-11-24 : Update to a single html file with chinese and English version.
• 2025-11-12 : Support .NET10

Introduction [中文版]

Blazor WASM Packager can package all Blazor WebAssembly program files, including js,wasm,dll,json,dat and other files, into a single JS file after GZIP compression. It greatly simplifies the deployment process, optimizes application loading performance, and enables cross-origin calls for Blazor WASM. <br/> For example, for the Blazor WASM application [DCWriterApp], there are contains 61 files totaling 36.5MB. After packaging, a single JS file is generated with a size of only 15.2MB, achieving a compression ratio of 41%. Additionally, deploying with this single JS file improves the application's loading speed and avoids cross-origin resource call issues.

| Inconveniences of standard Blazor WASM | After packaging | |----------------------------------------|-----------------| | 61 files, totaling 36.5MB, including various types such as dll, js, wasm, dat, etc. | Single JS file, 15MB | | Does not support cross-domain calls | Supports cross-domain calls | | Does not support "file://" local file system calls | Supported | | Does not support Election front-end file packaging technology | Supported | | Inconvenient for customer deployment, version updates and rollbacks | Convenient | | Contains DLL files (sensitive file type), which may conflict with customer security policies | None |

Demo for Blazor WASM without _framework folder

• https://dcsoft-yyf.github.io/BlazorWASMPackager/demoFiles/BlazorSample
• https://dcsoft-yyf.github.io/DCWriterApp/index.html

Screen snapshort

<img src="https://raw.githubusercontent.com/dcsoft-yyf/BlazorWASMPackager/refs/heads/main/BlazorWASMPackager.png"/>

Benefits

1. Ease of Use

   • This software contains only one file: BlazorWASMPackager.html. That's right, just one HTML file!
   • This HTML file is directly placed in the root folder of the published Blazor WebAssembly program (usually the wwwroot folder) and can be used by opening it with a mainstream browser, without relying on any third-party software.
   • Provides visual progress feedback and detailed processing logs
   • Supports custom output file names and script merging rules

2. Overcoming Cross-Origin and Local Execution Restrictions

   • Resolves cross-origin resource calling issues (CORS) in traditional Blazor WASM applications, avoiding cross-origin requests through resource embedding
   • Supports direct application launch from the local file system (file:// protocol) without relying on a web server
   • Can be used in offline scenarios or local demonstration environments without the need to configure server CORS policies

3. Simplified Deployment Process

   • Merges dozens or even hundreds of scattered resource files into a single JS file, reducing the number of deployment files
   • Simplifies software file deployment, network caching, version upgrade and rollback work
   • Reduces network request overhead during multi-file transmission
   • Reduces the risk of network firewalls or proxies restricting multi-file requests

4. Improved Loading Performance

   • Applies maximum-level GZIP compression to all resources, significantly reducing transmission size
   • Reduces the number of HTTP requests and lowers the impact of network latency
   • Supports custom script minification to remove redundant code

5. Enhanced Deployment Flexibility

   • The generated single file can be easily integrated into various static resource hosting services
   • Supports environment adaptation for micro-frontend architectures (MicroApp/ QianKun)
   • Facilitates version management and implementation of caching strategies

How I Developed This Software?

I developed this software with the help of Doubao AI ( www.doubao.com ). First, I used the following prompts to create the main body of this HTML file step by step:

1. Generate an HTML page with JS code to implement the following functions: 1.Parse the _framework/blazor.boot.json file in the current path, and parse the attribute names under the resources/runtime|assembly|runtimeAssets|pdb nodes in it. 2.Use this attribute name as the file name, then download these files, obtain the binary content, compress it using GZIP, and convert it to a Base64 string. Wrap the Base64 string, with 128 characters per line. 3.Create a new string in JavaScript format. Then define "window.__DCFileContents = { "file name": "Base64 string" }" 4.Provide a "Download" button on the interface to load the generated JS string using the JS MIME type.

2. Do not use pako; use the browser's built-in GZIP module directly.

3. This is a Blazor WASM program packager; modify the text description of the HTML.

4. The Base64 string should not be too long; it should wrap automatically after 128 characters, and the output text should be automatically appended and displayed at the bottom. Clear the interface of the debug output text before each generation, then start appending and displaying the debug output text.

5. Do not output a preview of the Base64 content; remove the current debug text from it, and only keep the debug text appending method at the bottom for output.

6. The width of the debug output text box is 100%, and a progress bar is added below it. Remove the status element in the middle.

7. The debug output text box has a fixed initial width; the progress bar displays progress text prompts in the middle. Add copyright information: "Copyright © Nanjing Duchang Information Technology Co., Ltd."

8. The final generated Base64 string in JS does not wrap automatically after 128 characters. 2. Program error: BlazorWASMPackage.html:260 Error processing file dotnet.wasm: Maximum call stack size exceeded, this file will be skipped processAndDownload @ BlazorWASMPackage.html:260 BlazorWASMPackage.html:260 Error processing file icudt_CJK.dat: Maximum call stack size exceeded, this file will be skipped The width of debugOutput should be 100%, and the Base64 string in the finally generated JS must wrap automatically after 128 characters. It has nothing to do with .csproj; modify the JS in the HTML to ensure that the Base64 string in the finally generated JS wraps automatically after 128 characters.

9. Modify uint8ArrayToBase64(), convert every 32 bytes here, then add a line break and carriage return character, and directly generate a BASE64 string with line breaks here. The progress bar text is left-aligned.

10. In uint8ArrayToBase64(), each group of bytes is 129 to avoid mismatched Base64 conversion lengths.

11. Do not use JSON intermediate format conversion; directly concatenate to generate JS strings.

12. For Base64 string output, use the ` ` format to avoid \n escape characters, and output the Base64 string with line breaks directly in JS.

13. All byte lengths here are formatted for output, using KB and MB units according to the size. Accurate to two decimal places. Include blazor.boot.json in the packaging. Use the maximum compression ratio for GZIP. Add a manual click download link in the summary report. Reset the progress bar after processing is completed. Adjust the color of the progress bar; the blue background with black text is unclear.

14. The generated JS file name uses the entryAssembly value under bool.json plus the suffix ".published.js".

15. Files with empty hashes cannot be skipped; all files must be processed unconditionally.

16. Add a multi-line text box to allow users to enter several JS file names, then during packaging, read these JS files in the _framework folder, merge them into one Merge.js, and participate in the packaging. If not specified by the user, Merge.js will not be generated.

17. The JS listed in boot.json must be packaged compulsorily and not merged into merge.js. The text box is for users to enter custom script .js file names. In addition, the first line of the finally generated js file must display the current date and time.

18. Add a checkbox to allow users to choose whether to delete comments and meaningless spaces in mergs.js.

19. Add a single-line text box for entering a custom final JS file name; if empty, the default file name is used.

20. Simplify the debug output text; by default, do not minify merge.js spaces and comments. Ensure that the merge.js minification result is correct.

21. For strings in JS, take into account multi-line strings like ` `, and regular expressions that may appear in JS code; they must not be damaged.

In this way, I used AI to create the initial version, then made subsequent modifications manually. Finally, the current version was formed.

Code Execution Process

I. Initialization Phase

1. Page Loading Preparation

   • Initializes DOM element references (progress bar, log area, buttons and other interactive components)
   • Resets the progress bar status to "Ready" (0%)
   • Clears the log output area
   • Disables the download button to prevent duplicate clicks

2. User Parameter Collection

   • Reads the content from the output file name input box (uses default naming rules when empty)
   • Parses the custom JS file list (one path per line, relative to the _framework folder)
   • Checks the status of the "Minify custom scripts" checkbox (determines whether to remove comments and redundant spaces)

II. Core Processing Flow

Step 1: Browser Compatibility Verification

• Detects whether the current browser supports the CompressionStream API (used for GZIP compression)
• Terminates the process and prompts: "Please use the latest version of Chrome, Edge or Firefox browser" if not supported

Step 2: Parse Application Configuration File

1. **