Electron.NET: running ASP.NET Core and Blazor inside an Electron shell

The problem Electron.NET solves for .NET web developers

A team with a working ASP.NET Core application usually has the hard part done: routing, dependency injection, Razor Pages or MVC views, authentication, and a build pipeline. What it does not have is a desktop window. Shipping that app as a desktop product normally means either rewriting the UI in a native toolkit or hand-writing a host process that starts a web server, waits for it to listen, opens a browser view, and shuts everything down cleanly on exit.

Electron.NET targets that second path. The README describes it as a way to build cross-platform desktop applications with .NET 6, 8 or 10, from console apps through ASP.NET Core (Razor Pages, MVC) to Blazor, with Electron handling presentation. The intended reader is a .NET developer who wants the desktop shell without leaving the ASP.NET hosting model.

The current line is ElectronNET.Core, described in the README as a modernization that preserves full API compatibility with the older Electron.NET. That compatibility claim matters if you have an existing Electron.NET project, because it suggests the migration is mostly about package names and the startup callback rather than a rewrite of your window code.

How Electron.NET wires .NET and Electron together

The mechanism is a two-process arrangement. Your .NET application is the host. Electron runs alongside it and supplies the Chromium window. The README says the classic setup still has an ASP.NET host run by the Electron side, but that both .NET and Electron can now launch the other for better lifetime management.

That second sentence is the interesting design change. If either side can start the other, you are no longer locked into one startup order, which is what makes the console-app mode possible. The README states that when you do not need a local web server, for example when running content from files or remote servers, you can drop the ASP.NET stack altogether and use a lightweight console app instead. In that mode Electron is still the presentation layer, but there is no Kestrel process to manage.

The API surface is exposed through ElectronNET.API and ElectronNET.API.Entities. Window creation goes through Electron.WindowManager.CreateWindowAsync, and the returned window exposes an OnReadyToShow event that the README's examples use to delay showing the window until the content is ready. This is a small detail with a visible payoff: without it, users see a white rectangle while the page loads.

Installing ElectronNET.Core and opening a first window

The README lists four NuGet packages: ElectronNET.Core, ElectronNET.Core.API, ElectronNET.Core.AspNet and ElectronNET.Core.Templates. For an ASP.NET Core project the README says to create the project and then add two of them.

dotnet add package ElectronNET.Core
dotnet add package ElectronNET.Core.AspNet

Before any of that, the README states the requirements: .NET 8/10 or later, an operating system supported by .NET 8 or .NET 10, and Node.JS at version 22.x or above. The Node requirement is the one people miss, and it is a real deployment constraint rather than a build-time detail.

With the packages in place, a minimal API host enables Electron through an extension method on the builder. The README's minimal API example registers Razor Pages, calls AddElectron for dependency injection, and passes a callback to UseElectron.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddElectron();
builder.UseElectron(args, async () =>
{
    var browserWindow = await Electron.WindowManager.CreateWindowAsync(
        new BrowserWindowOptions { Show = false, AutoHideMenuBar = true });
    browserWindow.OnReadyToShow += () => browserWindow.Show();
});

The callback is the part worth reading twice. The README notes that providing a callback to UseElectron is new in Electron.NET Core and that it exists so you know the right moment to set up your application UI. If you port an older project and leave the callback out, you have no defined point at which to create the window.

For Blazor the same shape applies, with one addition. The README's Blazor example sets IsRunningBlazor to true in BrowserWindowOptions and marks it as crucial, because it configures the renderer so Blazor runs without interference, including hot module replacement during development. The example also sets AutoHideMenuBar on Windows and Linux only.

To run it, the README says to press F5 in Visual Studio or use dotnet for debugging. The README points to the wiki for complete API documentation, and warns that the linked getting-started video has not been updated for the ElectronNET.Core changes and is therefore partially outdated.

Where Electron.NET is the wrong tool

The dependency chain is long. A desktop app built this way carries the .NET runtime, the ASP.NET stack when you use it, Node.js 22.x or above, and the Electron runtime. Each layer has its own update cadence and its own security surface. Electron in particular ships a bundled Chromium, and the README does not state which Electron version ElectronNET.Core 0.6.0 pins or how that pin is updated. That silence is the thing to resolve before you plan a release, not after.

The README also does not document rollback, downgrade steps, or a migration path from the pre-Core Electron.NET packages. The compatibility claim is about API shape, not about a tested upgrade procedure.

If your application is a small utility, a background service, or something that must start in tens of milliseconds, this architecture is the wrong shape. A console app with a native UI toolkit, or a service with no window at all, will be smaller and simpler. Electron.NET earns its cost when the UI already exists as web content and the team already knows ASP.NET.

Electron.NET against WebView2 and MAUI Blazor Hybrid

The closest alternatives for a .NET desktop UI are WebView2 on Windows and Blazor Hybrid through .NET MAUI. The difference is in what renders your pages and where the app can run.

WebView2 embeds the Edge runtime that is already present on Windows. That means no bundled browser engine and a smaller install, but it is a Windows-only story. Electron.NET bundles its own Chromium through Electron, which is why the README can describe the output as cross-platform across Windows, Linux and macOS rather than Windows alone.

Blazor Hybrid renders Razor components through a native control host instead of a browser engine. It fits teams that want native controls and platform integration, and it does not require Node.js. Electron.NET instead keeps the browser model intact, which is what makes existing Razor Pages and MVC views and Blazor WebAssembly components usable with minimal change. If your UI depends on browser APIs, CSS behavior or JavaScript interop, that continuity is the reason to pick Electron.NET over a hybrid renderer. If it does not, the hybrid path is lighter.

Maintenance, release cadence and the MIT licence

The repository is not archived, and the last push was on 2026-09-10. Recent releases are ElectronNET.Core 0.6.0 on 2026-09-07, 0.5.2 on 2026-08-03 and 0.5.1 on 2026-06-08. The version numbers are still in the 0.x range, which is worth weighing: the README makes a compatibility promise with older Electron.NET, but a 0.x line can still change shape between minors.

The repository carries a Changelog.md at the top level, alongside Directory.Build.props, Directory.Packages.props and a nuke/ directory with build.cmd, build.ps1 and build.sh. If you need to know what moved between 0.5.2 and 0.6.0, that file and the release notes are where to look; the README does not summarize version differences.

The licence is MIT. That permits commercial and closed-source use, and it places the usual obligation on you to keep the copyright and permission notice with the code. It does not cover the Electron runtime, Chromium or Node.js, which carry their own licences. This is not legal advice; check those terms against how you plan to distribute the application.

Editorial conclusion

Adopt Electron.NET if your application is already a .NET web app with Razor Pages, MVC or Blazor and you want a desktop window without rewriting the front end. Skip it if you need a small native binary, or if you cannot ship Node.js 22.x and the Electron runtime alongside your app. Before committing, verify the pinned Electron version and its security patch cadence, confirm that UseElectron runs the callback that creates your first BrowserWindow, and check the Changelog.md and release notes for the version you intend to pin, since the README's linked getting-started video is marked as partially outdated for ElectronNET.Core.

Frequently asked questions

Official sources

1. ElectronNET/Electron.NET on GitHub
2. License: MIT
3. Project website
4. README
5. Releases