PeakSWC.RemoteBlazorWebView.WindowsForms 11.0.0

dotnet add package PeakSWC.RemoteBlazorWebView.WindowsForms --version 11.0.0
                    
NuGet\Install-Package PeakSWC.RemoteBlazorWebView.WindowsForms -Version 11.0.0
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="PeakSWC.RemoteBlazorWebView.WindowsForms" Version="11.0.0" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="PeakSWC.RemoteBlazorWebView.WindowsForms" Version="11.0.0" />
                    
Directory.Packages.props
<PackageReference Include="PeakSWC.RemoteBlazorWebView.WindowsForms" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add PeakSWC.RemoteBlazorWebView.WindowsForms --version 11.0.0
                    
#r "nuget: PeakSWC.RemoteBlazorWebView.WindowsForms, 11.0.0"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package PeakSWC.RemoteBlazorWebView.WindowsForms@11.0.0
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=PeakSWC.RemoteBlazorWebView.WindowsForms&version=11.0.0
                    
Install as a Cake Addin
#tool nuget:?package=PeakSWC.RemoteBlazorWebView.WindowsForms&version=11.0.0
                    
Install as a Cake Tool

RemoteBlazorWebViewTutorial

Microsoft is currently supporting two Blazor WebView Controls in .NET 11. One control (Microsoft.AspNetCore.Components.WebView.Wpf) targets Windows Presentation Foundation (WPF) apps and the other (Microsoft.AspNetCore.Components.WebView.WindowsForms) targets Windows Form (WinForms) apps. These Microsoft controls enable developers to create user interfaces for desktop apps using Blazor web technology. Desktop apps using Blazor have the full feature set and performance of .NET 11 and are not constrained like a Blazor WebAssembly app.

The Remote versions of the Blazor WebView Controls (PeakSWC.RemoteBlazorWebView.Wpf and PeakSWC.RemoteBlazorWebView.WindowsForms) serve as a drop-in replacements for the Microsoft controls, with the added ability to access the user interface over a secure connection to a public server using a web browser. This is achieved by setting up a secure server (RemoteWebViewService) in the cloud and pointing your browser to it. With a few minor changes, you can run your app locally or remotely control your application.

The RemoteBlazorWebView package allows developers to create a Blazor UI on Windows, Mac, and Linux. RemoteBlazorWebView is based on Microsoft's WebView control and Photino.Blazor. It shares the same server with the WinForms and Wpf controls (RemoteWebViewService).

Use Cases

The primary use case is to share a desktop application with someone who is somewhere else: a service technician, a coworker, a support desk. Typically, the application is behind a corporate firewall and is not easily reached from outside. The Remote Blazor controls let the desktop application be started in "Remote" mode, which generates a unique Url for the remote user. The person at the PC keeps using the app in its own window, hands control to the remote user when they want help, and takes it back when they are done.

Another use case is to be able to monitor data that is behind a firewall or on a private network without the cost and complexity to store the data externally. For example, if a brewer wanted to monitor fermentation data such as PH, Gravity, and Pressure they could build an app showing real-time graphical data using Blazor components and, with only a couple of changes, be able to view the user interface with a web browser from outside of the firewall.

How it works

RemoteBlazorWebView.Wpf has two modes of operation. In the first default mode, it works just like the Microsoft BlazorWebView Controls (see BlazorDesktopWPF). In the second mode, a url is specified on the control's properties. In this mode the app still runs on the PC, but its user interface goes through a server, where browsers can show it and send their input back. Hosting the server (RemoteWebViewService) in the cloud allows you to reach an application which is behind a firewall or does not have a static IP address.

What a remote app can do:

  • Sharing control. The app shows in its own window with the person at the PC in control, and a remote user joins from a browser and is handed control. One owner, one remote user, any number of read-only viewers. This is the recommended arrangement.
  • A session bar in every browser: who has control, Give control / Take control, Copy link, and Restart app. It is opt-in: the built-in bar where you put its placeholder, your own markup from a template, or no bar at all.
  • Unattended sessions, where the remote user gets control as soon as they join.
  • A voice call between the person at the PC and the remote user.
  • Browser only, the simplest arrangement: the app runs only in the browser and the window shows the link. The sample programs below start this way.

A source generator writes the setup for you: mark the window with [RemoteBlazor] and call the generated InitializeRemoteBlazor(). See Converting a WPF Blazor Application to a Remote WPF Blazor Application.

Demo Video

RemoteBlazorWebView

Download and Run Demo

  • Download the latest Release.zip under the Assets folder from https://github.com/budcribar/RemoteBlazorWebViewTutorial/releases

  • Extract the files

  • Run either the WinForms (RemoteBlazorWebViewTutorial.WinFormsApp.exe) or the Wpf Sample Program (RemoteBlazorWebViewTutorial.WpfApp.exe) which shows the Blazor UI running normally

  • Next start the server and run the sample application through the browser

    • Open a powershell window and execute RemoteWebViewService in the background
    .\RemoteWebViewService &
    
    • Run the sample program with the local server option
    .\RemoteBlazorWebViewTutorial.WpfApp.exe -u=https://localhost:5001
    
    • Click the link in the sample program
  • Finally, Run the sample program and use the secured cloud server

    .\RemoteBlazorWebViewTutorial.WpfApp.exe -u=https://server.remoteblazorwebview.com:34544
    
    • Click the link in the sample program

Build and Run Demo

  • Build from the command line (no Visual Studio required)
dotnet build -p:EnvBuildMode=Package

EnvBuildMode=Package uses the published PeakSWC NuGet packages. Without it the build looks for a sibling RemoteBlazorWebView source checkout.

  • Run an app with a server URL and, optionally, a fixed Guid
dotnet run --project RemoteBlazorWebViewTutorial.WinFormsApp -- -u=https://localhost:5001 -i=<guid>

Browse to <server url>/app/<guid>. Each Guid can only be opened by one browser: a second visit returns 409 "Locked" by design.

  • Try a shared session with the converted sample
dotnet run --project WpfBlazorRemote

The app opens in its own window with you in control. Press Copy link, open the link in a browser, then press Give control. Add -- --unattended or -- --voice to try those.

  • Install the RemoteWebViewService
dotnet tool update -g PeakSWC.RemoteWebViewService --version 10.*-* 
  • Start the server
RemoteWebViewService
  • Open the RemoteBlazorWebViewTutorial.sln with Visual Studio

  • Select the Local Profile from the dropdown next to the Run button and click on run

  • Make sure the RemoteBlazorWebViewTutorial.WpfApp is set as Startup Project

  • Next we will run the application remotely

  • Select the Remote Profile from the dropdown next to the Run button and click on run

  • A main window will come up with a URL. Click on it

  • At this point the sample blazor app will be running in a web browser served from RemoteWebViewService!

  • Finally, we will run the application from a cloud server (https://server.remoteblazorwebview.com:34544)

  • Select the Cloud Profile from the dropdown next to the Run button and click on run

  • A main window will come up with a URL. Click on it

  • At this point the sample blazor app will be running in a web browser served from https://server.remoteblazorwebview.com:34544. The server is setup for demo purposes only and has no login. Contact me at budcribar@msn.com if you would like help setting up a production server.

Using your own server

The cloud server uses a Let's Encrypt certificate. If you host your own server with a self-signed certificate, the client machine must trust that certificate (for example by importing it into the Windows Trusted Root store).

Security

Each time a client application starts it attaches to the server with a unique Guid. This Guid is part of every link to the application and provides the first layer of security: treat a link as a secret.

  • The application's own page (/app/<guid>) is locked once a browser attaches to it, and no other browser can open it.
  • In a shared session, the link the remote user joins at (/mirror/<guid>) is read-only. Anyone who has it can watch. Only the first person to join can be handed control, and only the person at the PC, or whoever currently has control, can hand it over.
  • The person at the PC can always take control back.

The demo version of the RemoteWebViewService does not include authentication but it can be built and configured with Azure AD B2C. When built with Azure AD B2C authentication, the server requires that users are authenticated in order to access the endpoints which serve up the demo application user interface. The server code is hosted in the RemoteBlazorWebView github repository and includes a Visual Studio project to build the server. This added layer of security should be sufficient for most use cases but the server can be further locked down with firewall rules if needed.

Changing the default server port

Create an appsettings.json file with the contents: (Replace 5002 with the desired port)

{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://localhost:5002"
      }
    }
  }
}

  • Copy the appsettings.json into the directory
cd %USERPROFILE%\.dotnet\tools

Convert To Remote

Converting a WPF Blazor Application to a Remote WPF Blazor Application: the conversion itself, then sharing control, the session bar, unattended sessions, voice and restarting.

The samples in this repository:

Project What it shows
WpfBlazor A plain WPF Blazor app, the starting point of the conversion
WpfBlazorRemote The same app converted, running as a shared session
RemoteBlazorWebViewTutorial.WpfApp, .WinFormsApp The browser-only arrangement with a mirror in the window, set up by [RemoteBlazor(Mirror = true, RestartOnRefresh = true, ShutdownOnDisconnect = true)]
RemoteBlazorWebViewTutorial The same on Photino (Windows, Mac, Linux), set up by hand: the generator covers the WPF and WinForms controls

Move a Component into Its Own Process

Moving a Blazor Component into Its Own Process: when it's worth it, and how to do it with remote components

Product Compatible and additional computed target framework versions.
.NET net11.0-windows7.0 is compatible. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
11.0.0 0 11/11/2026
11.0.0-rc2 65 10/25/2026
10.0.15.1 0 11/11/2026
10.0.15 36 11/11/2026
10.0.14 73 11/8/2026
10.0.13 112 10/19/2026
10.0.0-preview5 260 6/14/2025
10.0.0-preview4 326 5/14/2025
10.0.0-preview3 154 4/12/2025
9.0.22 62 11/6/2026
9.0.21 111 10/15/2026
9.0.6 439 6/15/2025
9.0.5 446 5/14/2025
9.0.4 303 4/12/2025
9.0.2 370 2/16/2025
9.0.1 339 1/18/2025
9.0.0 334 11/14/2024
9.0.0-rc2 191 10/26/2024
8.0.11 325 11/14/2024
8.0.10 368 10/10/2024
Loading failed

Based on maui 11.0.0

Changes since 11.0.0-rc2
Merge branch 'claude/net11-port-shared-control': net10's shared control work on the released .NET 11 (11.0.0)
net11: no pack hook or package reference that net11 had already removed
Release process doc: net11 numbers and how EditWebView runs on this line
Upstream source from aspnetcore 11.0.0 and MAUI 11.0.10 (EditWebView run)
net11: keep net11's own module-initializer end-to-end tests
net11: the ported cache test passes the cache-control value net11's helper needs
net11 on the released .NET 11: SDK 11.0.100, packages 11.0.0, version 11.0.0
Port net10 since the last sync: shared control, owner key, sign-in providers, opt-in session bar
Document EditWebView in the release process.
Merge pull request #80 from budcribar/claude/net11-escape-release-notes
Escape commas and semicolons in the release notes passed to dotnet pack
Merge pull request #77 from budcribar/claude/net11-port-net10-release
Retarget the ported net10 projects to net11
Prepare NuGet release packaging, CI test coverage, and remote component contract hardening
RemoteComponentHost: ExitWhenInputCloses, exit when stdin ends instead of polling
Keep remote component frames from restarting when the app is mirrored
Mark agent registry (AgentHub/AgentAdmin) experimental (RWV001)
Restore Authorization package references in RemoteWebViewService.Lib
Describe agents and the embedded relay without naming one app
Remote components README: use a generic contract example
Remote components: describe the use generically
Add the [RemoteComponentContract] source generator
Add remote components: runtime and the WPF RemoteComponentHost
Add ReverseMirror to [RemoteBlazor]
Add the [RemoteBlazor] source generator
Port the net9 test-runner and window-sizing fixes.
Install nvm-windows when RunTests.ps1 cannot find nvm.
Throw the frame-ancestor error after the scan.
Name the first invalid frame ancestor after valid ones.
Merge pull request #66 from budcribar/net11-bugbounty-fixes
Port Bug02, Bug03 (dispose-on-throw), Bug06, Bug15, Bug44, and Bug60 fixes and regression tests
Pin net11 to the rc.3 SDK and the patched Graph/Kiota line.
Update net11 dependencies to current rc.3 and stable releases.
Pin global.json to the SDK shipped by the 11.0-preview image.
Fix Sonar reliability and security findings that are safe to backport.
Merge pull request #65 from budcribar/claude/net11-port-net10
Target net11 in the ported embedded-relay library, sample and server branch CI
Let pages in opaque-origin sandboxed iframes connect
Synchronize primary browser scrolling to read-only mirrors
EmbeddedRelayWpf: embed wwwroot so a single-file publish works
EmbeddedRelayWpf: target Windows 10 SDK and show crashes
Copy RemoteWebViewService.Lib into the Docker build and server CI paths
Split RemoteWebViewService into an embeddable library for net10
Gate AgentAdmin starts with AGENT_ADMIN_KEY and guard in-flight starts
Add the agent registry (AgentHub / AgentAdmin) to RemoteWebViewService
Add Linux container mode with Kestrel TLS/HTTP2 for Railway TCP proxy.
Remove net10-only Program.IsContainerMode reference from Startup.cs on net11
Add in-memory event log provider for GetLoggedEvents on Linux
Fail the performance check when the baseline has no samples.
Add the net11 intermittent CI failure log.
Record the nuget.org user and required reviewer.
Generate PackageReleaseNotes for the maintainer to commit.
Spell package suffixes without a dot and add a patch counter.
Draft the package release workflow without a NuGet push.
Add a draft release workflow skeleton.
Read Chrome output on a dedicated thread before waiting for DevTools.
Retry a timed-out DevTools probe and keep the Chrome module classes in one collection.
Measure TestConnectedEvent from the Connected signal, not the pause.
Note SYSLIB1044 on the base-href regex as won't fix.

Full list: https://github.com/budcribar/RemoteBlazorWebView/compare/11.0.0-rc2...24c67bf600e845754a3edfc138ccc97c6f2ccb00