How to Fix Avalonia WASM net_uri_notabsolute Error

How Did We Encounter the Avalonia WASM StorageProvider Exception?

While working on replatforming an enterprise engineering simulation suite, our goal was to bring a heavy, desktop-bound application to the browser using Avalonia UI and WebAssembly (WASM). The application allowed engineers to run complex physics and structural simulations based on parameters defined in local XML files.

During the initial development phases, everything worked seamlessly on the desktop targets (Windows and macOS). However, the moment we deployed the WASM build to a sandboxed localhost environment on Google Chrome, we hit a wall. Users could open the file picker to select their XML simulation models, but immediately upon selection, the application crashed.

The console threw an unfamiliar exception: net_uri_notabsolute. It became clear that the assumptions we made about file system access on the desktop did not translate to the browser’s security sandbox. We realized that handling cross-platform I/O requires a fundamentally different approach. This challenge inspired this article so other teams navigating the complexities of Avalonia WASM can avoid the same file-handling pitfalls.

Why Do Local File Paths Fail in a WebAssembly Architecture?

The core of the business use case relies on users importing legacy XML configuration files directly from their local drives into the simulation platform. In a traditional .NET desktop environment, when an application requests a file via a dialog, the OS returns an absolute path (e.g., C:Modelsengine_test.xml). The application then uses standard System.IO.File methods to open and read that path.

WebAssembly runs entirely within the browser’s constrained security sandbox. To protect user privacy and system security, modern browsers do not expose the host operating system’s raw file paths to web applications. When you use the Avalonia StorageProvider in a WASM context, the browser handles the actual file selection natively. It hands back an opaque reference to the file’s binary data—not a physical path.

When organizations decide to hire software developer teams to migrate legacy systems to the web, bridging this gap between desktop I/O paradigms and web security models becomes one of the most critical architectural considerations.

What Causes the net_uri_notabsolute Error in Avalonia?

By analyzing the application logs and stepping through the WASM debugging tools, we isolated the issue to a specific line in our file handling service.

Once the file picker returned the IStorageFile reference, our code was attempting to extract the absolute path to pass it down to a legacy XML parsing library:

string filename = file.Path.AbsolutePath;

In WebAssembly, the IStorageFile.Path property does not contain a standard OS URI. It often evaluates to a browser-specific internal blob reference or an unsupported relative URI schema. When the .NET runtime attempts to access the AbsolutePath property of a URI that isn’t fully qualified or absolute in the traditional sense, it throws a System.UriFormatException containing the net_uri_notabsolute error.

The failure was an architectural oversight. We had tightly coupled our data ingestion layer to physical file paths, violating the cross-platform abstraction that Avalonia’s StorageProvider is designed to facilitate.

How Did We Approach Fixing the WASM File Access Issue?

To resolve the file access limitation without breaking desktop compatibility, we explored several potential pathways. The goal was to find a unified abstraction that worked reliably across both environments.

Attempting JavaScript Interop for File Paths

Our initial thought was to use JS Interop to somehow extract a usable path or inject the file into the WASM virtual file system. We considered bridging a standard HTML <input type="file"> element with our .NET backend. However, this approach defeated the purpose of using Avalonia’s unified StorageProvider and added unnecessary complexity to our UI layer.

Using In-Memory Blob URIs

We also considered converting the browser’s file reference into a Blob URI and attempting to fetch it via HTTP within the WASM sandbox. While technically feasible for small XML files, this approach introduces memory overhead and scales poorly for larger simulation models. It also breaks the desktop implementation, meaning we would have to write platform-specific compiler directives (#if BROWSER), which we wanted to avoid.

Adopting Pure Stream-Based I/O

The most robust solution was to stop treating the selected file as a “path” and start treating it as a “stream”. The IStorageFile interface in Avalonia provides an OpenReadAsync() method. By reading the stream directly, we bypass the need for a file path entirely. The browser handles the underlying stream securely and the desktop OS does the same. This is a standard best practice companies should expect when they hire dotnet developers for enterprise modernization.

What is the Proper Implementation for Avalonia WASM File Selection?

We refactored our file ingestion service to exclusively use stream-based operations. Instead of passing paths to our XML parsers, we updated them to accept Stream objects.

Here is the sanitized, cross-platform implementation that resolved the net_uri_notabsolute error:

private async Task OpenModel(CancellationToken token)
{
    try
    {
        var filesService = App.Current?.Services?.GetService<IFilesService>();
        if (filesService is null)
            throw new InvalidOperationException("Missing File Service instance.");
        // Retrieve the cross-platform IStorageFile reference
        var file = await filesService.OpenModelAsync();
        if (file is null)
            return; // User canceled the dialog
        // DO NOT use file.Path.AbsolutePath in cross-platform scenarios
        // Instead, open a read stream directly from the storage provider
        
        await using var stream = await file.OpenReadAsync();
        using var reader = new StreamReader(stream);
        
        string xmlContent = await reader.ReadToEndAsync(token);
        
        // Pass the string or stream to the parsing engine
        ProcessSimulationModel(xmlContent);
    }
    catch (Exception ex)
    {
        // Log cross-platform exceptions appropriately
        Console.WriteLine($"Failed to open model: {ex.Message}");
    }
}

Validation Steps:

• We verified that the desktop build still successfully routed the physical file through the FileStream implementation behind the scenes.
• We deployed the WASM build to the local browser sandbox and confirmed that large XML models were successfully read into memory without triggering URI exceptions.
• We monitored browser memory usage to ensure the stream was properly disposed of after reading, avoiding memory leaks in the browser tab.

What Can Engineering Teams Learn from WASM Sandbox Constraints?

Migrating desktop applications to the browser requires a shift in how engineers conceptualize system resources. Here are the key takeaways for teams adopting WebAssembly:

• Abstract All I/O Operations: Never assume the presence of a traditional file system. Always program against streams or abstract byte arrays rather than physical disk paths.
• Avoid Platform-Specific Properties: Properties like AbsolutePath may exist on interface contracts for legacy compatibility, but they are traps in sandboxed environments. Stick to the methods explicitly designed for cross-platform data retrieval.
• Stream Large Files: When dealing with large datasets (like engineering models), reading everything into memory at once can crash a browser tab. If you hire frontend developers for cross-platform web apps, ensure they understand how to chunk stream reads appropriately.
• Test WASM Targets Early: Do not wait until a feature is complete on desktop to test it in the browser. WASM introduces unique threading, networking and I/O restrictions that dictate architectural decisions from day one.
• Depend on Inversion of Control (IoC): Our use of IFilesService was a good practice. It allowed us to swap the internal implementation without affecting the UI layer, proving the value of strict dependency injection in cross-platform codebases.

How Do We Summarize the WebAssembly File Access Fix?

The transition from desktop architectures to WebAssembly brings significant benefits in deployment and accessibility, but it demands strict adherence to browser security models. The net_uri_notabsolute exception in Avalonia is a direct result of relying on desktop-centric path structures in a pathless, sandboxed environment. By refactoring our data access layer to utilize pure stream-based I/O, we created a truly unified codebase that runs flawlessly on Windows, macOS and any modern web browser.

If your organization is navigating the complexities of replatforming legacy desktop applications to modern web architectures, our experienced engineering teams can help. contact us to discuss how we can support your next major cross-platform initiative.

Social Hashtags

#AvaloniaUI #WebAssembly #WASM #DotNET #CSharp #DotNETDevelopment #CrossPlatformDevelopment #WebDevelopment #SoftwareDevelopment #StorageProvider #AppDevelopment #DeveloperTips