Why Copilot Studio’s Move to .NET 10 WebAssembly Boosts Performance

Microsoft Copilot Studio, the low-code platform for building intelligent conversational agents, recently upgraded its underlying web technology stack to .NET 10 WebAssembly (WASM). This upgrade follows a previous migration from .NET 6 to .NET 8 that delivered measurable performance gains. Now, with .NET 10, the team has unlocked even more improvements—smoother deployments, automatic asset fingerprinting, and smaller AOT outputs—all while maintaining compatibility with existing workflows. This article breaks down what changed, how the migration went, and what it means for developers using Copilot Studio.

A Seamless Migration to .NET 10

Moving a production WASM application from .NET 8 to .NET 10 proved remarkably straightforward for the Copilot Studio team. The primary task was updating the target framework moniker in the project files—from net8.0 to net10.0—and verifying that all third-party dependencies aligned with the new runtime. No breaking API changes or unexpected configuration hurdles surfaced. After thorough testing, the .NET 10 build entered production without incident. This kind of frictionless upgrade shows Microsoft's commitment to backward compatibility within the .NET ecosystem, especially for WASM workloads.

Automatic Fingerprinting: Deployment Gets Simpler

One of the most impactful enhancements in .NET 10 for WebAssembly projects is the automatic fingerprinting of WASM assets. When you publish a .NET WASM app, each static resource—such as .wasm files, .dll assemblies, and .dat files—now receives a unique identifier appended to its filename. This identifier is a cryptographic hash of the file's contents, providing built-in cache-busting and integrity verification without any manual intervention.

Previously, Copilot Studio had to implement a custom fingerprinting workflow to achieve the same result:

• Parse the blazor.boot.json manifest generated during publishing to enumerate all needed assets.
• Run a PowerShell script to rename each file, appending a SHA256 hash to the filename.
• Supply an explicit integrity hash from JavaScript when fetching each resource, which had to be kept in sync with the renamed files.

With .NET 10, all of that is eliminated. The runtime's dotnet.js entry point directly imports the fingerprinted assets, validates integrity automatically, and the old custom renaming script and manual integrity arguments are gone. The team simply deleted those helper scripts from their build pipeline. Existing client-side caching and validation logic that runs on top of these resources continues to work unchanged, because the file content hasn't altered—only the filename changed.

For developers who load the .NET WASM runtime inside a Web Worker, there's an important tip: set dotnetSidecar = true when initializing the runtime to ensure proper initialization in a worker context.

Smaller AOT Output Through WasmStripILAfterAOT

The second headline feature for .NET WASM in .NET 10 is that WasmStripILAfterAOT is now enabled by default for AOT (Ahead-of-Time) compilation builds. When you compile .NET code to WebAssembly using AOT, the original Intermediate Language (IL) for each method is no longer needed at runtime—the WASM bytecode contains all the instructions. In earlier versions of .NET, the IL was retained in the publish output, inflating the download size. .NET 10 strips that IL automatically by default, resulting in smaller .wasm and .dll files.

In .NET 8, this setting existed but defaulted to false, so developers had to explicitly opt in to the size savings. Now it's the default, so everyone benefits.

Copilot Studio’s Dual JIT/AOT Packaging

Copilot Studio uses an advanced packaging strategy that combines the best of both worlds: fast startup via JIT (Just-In-Time) compilation and maximum execution speed via AOT. They ship a single NPM package containing two engines:

• JIT engine – loads quickly and can start interpreting C# code almost immediately.
• AOT engine – takes longer to load but runs at near-native speed once ready.

At runtime, both engines are fetched in parallel. The JIT engine handles initial user interactions while the AOT engine finishes loading. Once AOT is ready, control is smoothly handed off. To keep the package size minimal, any files that are bit-for-bit identical between the JIT and AOT builds are deduplicated. However, because WasmStripILAfterAOT strips the IL from AOT assemblies, the AOT assemblies no longer match their JIT counterparts. As a result, fewer files can be deduplicated, but the overall benefit is still positive: the AOT engine is smaller than before, and the JIT engine remains unchanged. The net effect is a slight increase in total package size due to less overlap, but significantly faster loading for the AOT path and a better user experience overall.

Conclusion

The Copilot Studio team’s upgrade to .NET 10 WebAssembly demonstrates how incremental runtime improvements can yield real-world benefits. Automatic fingerprinting eliminates fragile custom scripts and reduces deployment complexity, while the default WasmStripILAfterAOT shrinks AOT payloads. The smooth migration itself underscores .NET’s strong forward compatibility. For anyone running .NET WASM applications, these changes are well worth adopting—they make your applications faster to load, easier to deploy, and more maintainable over time.