Converting Existing ASP.NET Core Web Application to a Local Desktop Application?

Hi,

Since you are targeting Windows specifically and using .NET 8, the choice largely depends on whether your existing application is already using Blazor or if it relies on MVC / Razor Pages.

Here is the breakdown of your questions to help you decide.

1. Blazor Hybrid (WPF/WinForms) Approach

Architecture:

In a Blazor Hybrid app (typically using .NET MAUI or WPF with BlazorWebView), your application does not run on a web server (Kestrel). Instead, the C# code runs directly in the native .NET desktop process, and the UI is rendered inside the system's embedded browser control (WebView2).

• Native Performance: Yes. Your C# business logic runs on the host machine’s .NET runtime, exactly like a standard desktop application. There is no WebAssembly (WASM) intermediate layer involved.
• Local File System Access: Yes. Because the C# code is running natively, you have full direct access to System.IO, the Windows Registry, and other OS APIs without needing bridges or HTTP calls. You can read/write files directly from your services.
• Caveat: This approach is seamless if your existing web app is built with Blazor. If your current app uses MVC or Razor Pages, you cannot simply "drop them in" to a BlazorWebView. You would need to migrate your .cshtml views to .razor components.

2. Electron.NET Approach

Architecture:

Electron.NET essentially bundles your standard ASP.NET Core application inside an Electron (Chromium + Node.js) shell.

• Does it use Kestrel? Yes. When the application starts, Electron.NET spawns a background process that runs your ASP.NET Core app on a local Kestrel server (usually on a random localhost port). The Electron window then navigates to that localhost URL.
• Native Process? It is a "hybrid" in a different sense. You have two distinct processes:
  1. The Node.js/Electron process (managing the window).
  2. The .NET/Kestrel process (running your API/Logic).
• Performance Disadvantages:
  • Memory: You are running a full Chromium browser instance plus a Node.js runtime plus the .NET runtime. This is significantly heavier than Blazor Hybrid (which uses the OS-shared WebView2).
  • Communication: Your UI (in the browser) talks to your Logic (in .NET) via HTTP/SignalR (network stack), whereas Blazor Hybrid talks via local interop (memory), which is faster.

3. Service Integration (DI) Best Practices

To adhere to DRY (Don't Repeat Yourself) and share DI between Web and Desktop:

1. Create a Shared Project: Move your logic (Services, EF Core context, models) to a Class Library (e.g., MyApp.Core).
2. Extension Method: Create a static class in that library to handle registration.

   
       // In MyApp.Core
   
       public static class DependencyInjectionExtensions
   
       {
   
           public static IServiceCollection AddMyApplicationServices(this IServiceCollection services)
   
           {
   
               services.AddDbContext<MyDbContext>();
   
               services.AddScoped<IMyBusinessService, MyBusinessService>();
   
               // ... all other shared services
   
               return services;
   
           }
   
       }
   
   

3. Usage:
   • In your Web Program.cs: builder.Services.AddMyApplicationServices();
   • In your Desktop MauiProgram.cs or App.xaml.cs: serviceCollection.AddMyApplicationServices();

Recommendation

Scenario A: Your app is using MVC / Razor Pages

• Choose Electron.NET. It allows you to wrap your existing request/response architecture without rewriting the UI layer. Blazor Hybrid does not support MVC/Razor Pages.

Scenario B: Your app is using Blazor (or you are willing to migrate Views to Components)

• Choose Blazor Hybrid (WPF or MAUI).
  • Efficiency: Much lower memory footprint (uses Shared WebView2).
  • Performance: Faster UI-to-Logic communication (no HTTP loopback).
  • Distribution: Produces a cleaner, smaller executable setup compared to bundling Node+Chromium.
  • Access: Native file system access is immediate and doesn't require IPC bridges.

For your case, Blazor Hybrid is generally the better technical choice.

Hope this helps.

File System Access Standard web apps can't access client files because the code executes on a remote server. However, with either Electron.NET or Blazor Hybrid, your code executes locally on the user's machine. This means you will have full native access to the file system (System.IO) regardless of which path you choose.

Electron.NET vs. Blazor Hybrid

Electron.NET: This is a true "Lift & Shift" solution. Because it runs a real Kestrel server in the background, your existing Controllers, Routes, and .cshtml Views work exactly as they do now. The trade-off: It is heavy. You are running the .NET Runtime + Node.js + Chromium. Expect 150MB+ RAM usage even for a simple app.

Blazor Hybrid: If your current UI relies on MVC or Razor Pages (.cshtml), you cannot simply drop it into Blazor Hybrid. You would need to rewrite the UI layer into Blazor Components (.razor). While this approach is much lighter on system resources, the migration effort is significantly higher.

Dependency Injection (DI) You generally shouldn't worry about porting your DI. Since DI is just interfaces and implementations, your existing logic is fully reusable in a desktop environment. The only code you might need to refactor is anything relying on web-specific features like Cookies or Session state, as those concepts don't translate directly to desktop apps.

The electron.net is most compatible with your current code. Yes it does run a kestrel server and will require an TCP/IP port and will be a two process application.

Hybrid Blazor does not use an internal webserver and is a single process application. But you would need to rewrite your code to Blazor. You could convert your core app to Blazor, but check the tradeoffs first.