PeakSWC.RemoteBlazorWebView.Wpf
10.0.14
See the version list below for details.
dotnet add package PeakSWC.RemoteBlazorWebView.Wpf --version 10.0.14
NuGet\Install-Package PeakSWC.RemoteBlazorWebView.Wpf -Version 10.0.14
<PackageReference Include="PeakSWC.RemoteBlazorWebView.Wpf" Version="10.0.14" />
<PackageVersion Include="PeakSWC.RemoteBlazorWebView.Wpf" Version="10.0.14" />
<PackageReference Include="PeakSWC.RemoteBlazorWebView.Wpf" />
paket add PeakSWC.RemoteBlazorWebView.Wpf --version 10.0.14
#r "nuget: PeakSWC.RemoteBlazorWebView.Wpf, 10.0.14"
#:package PeakSWC.RemoteBlazorWebView.Wpf@10.0.14
#addin nuget:?package=PeakSWC.RemoteBlazorWebView.Wpf&version=10.0.14
#tool nuget:?package=PeakSWC.RemoteBlazorWebView.Wpf&version=10.0.14
RemoteBlazorWebViewTutorial
Microsoft is currently supporting two Blazor WebView Controls in .NET 10. 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 10 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 (RemoteWebWindowService) 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 (RemoteWebWindowService).
Use Cases
The primary use case is to be able to share a desktop application controlling hardware with an external service technician. Typically, the application is behind a corporate firewall and is not easily accessed by the technician. The Remote Blazor controls enables the desktop application to be started in "Remote" mode which generates a unique Url for the technician to access the user interface.
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, all GUI interactions are sent to a server that can be accessed with a browser.
Hosting the server (RemotableWebViewService.exe) in the cloud allows you to remotely control an application which is behind a firewall or does not have a static IP address.
Demo Video

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.
- 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 needs to be specified on the Url in order to access the application and provides the first layer of security. The application is locked once a browser attaches to the server at a given Guid and no other browser instance has access.
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
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 | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0-windows7.0 is compatible. |
-
net10.0-windows7.0
- Google.Protobuf (>= 3.36.2)
- Microsoft.AspNetCore.Components.WebView.Wpf (>= 10.0.120)
- PeakSWC.RemoteBlazorWebView.RemoteComponents (>= 10.0.14)
- PeakSWC.RemoteWebView (>= 10.0.14)
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-rc2 | 72 | 10/25/2026 |
| 10.0.14 | 48 | 11/8/2026 |
| 10.0.13 | 408 | 10/19/2026 |
| 10.0.0-preview5 | 229 | 6/14/2025 |
| 10.0.0-preview4 | 327 | 5/14/2025 |
| 10.0.0-preview3 | 176 | 4/12/2025 |
| 9.0.22 | 53 | 11/6/2026 |
| 9.0.21 | 112 | 10/15/2026 |
| 9.0.6 | 1,910 | 6/15/2025 |
| 9.0.5 | 932 | 5/14/2025 |
| 9.0.4 | 323 | 4/12/2025 |
| 9.0.2 | 360 | 2/16/2025 |
| 9.0.1 | 317 | 1/18/2025 |
| 9.0.0 | 340 | 11/14/2024 |
| 9.0.0-rc2 | 177 | 10/26/2024 |
| 9.0.0-preview7 | 358 | 8/19/2024 |
| 9.0.0-preview6 | 153 | 7/29/2024 |
| 8.0.11 | 331 | 11/14/2024 |
| 8.0.10 | 1,570 | 10/10/2024 |
| 8.0.8 | 459 | 8/20/2024 |
Based on maui 10.0.14
Changes since 10.0.13
Merge pull request #79 from budcribar/claude/escape-release-notes
Escape commas and semicolons in the release notes passed to dotnet pack
Merge pull request #78 from budcribar/claude/fix-webview-version-test
Expect WebView 10.0.14 in the module serving version test
Merge pull request #76 from budcribar/fix/nuget-release-readiness
Merge pull request #75 from budcribar/claude/remote-component-exit-on-eof
Prepare NuGet release packaging, CI test coverage, and remote component contract hardening
RemoteComponentHost: ExitWhenInputCloses, exit when stdin ends instead of polling
Merge pull request #73 from budcribar/claude/agent-registry-experimental
Merge pull request #74 from budcribar/claude/mirror-safe-remote-frames
Keep remote component frames from restarting when the app is mirrored
Mark agent registry (AgentHub/AgentAdmin) experimental (RWV001)
Merge pull request #72 from budcribar/claude/fix-authorization-build
Bump NuGet packages to latest stable (staying on .NET 10)
Restore Authorization package references in RemoteWebViewService.Lib
Merge pull request #70 from budcribar/claude/remote-components-generator
Merge remote-tracking branch 'origin/net10' into claude/remote-components-generator
Merge pull request #69 from budcribar/claude/remote-components
Merge remote-tracking branch 'origin/net10' into claude/remote-components
Merge pull request #68 from budcribar/claude/remote-blazor-generator
Merge pull request #71 from budcribar/claude/generic-wording
Describe agents and the embedded relay without naming one app
Remote components README: use a generic contract example
Merge branch 'claude/remote-components' into claude/remote-components-generator
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 #67 from budcribar/net10-bugbounty-fixes
Port Bug02, Bug03 (dispose-on-throw), Bug06, Bug15, Bug44, and Bug60 fixes and regression tests
Set the net10 packages to 10.0.14 and the current Microsoft 10.0 libraries.
Fix Sonar reliability and security findings that are safe to backport.
Merge pull request #64 from budcribar/claude/net10-opaque-origin-frames
Let pages in opaque-origin sandboxed iframes connect
Merge pull request #62 from budcribar/claude/net10-embedded-server
Merge net10 (scroll sync) into claude/net10-embedded-server
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 in-memory event log provider for GetLoggedEvents on Linux
Add Linux container mode with Kestrel TLS/HTTP2 for Railway TCP proxy.
Fail the performance check when the baseline has no samples.
Add the net10 intermittent CI failure log.
Add the package release workflow for the net10 line.
Read Chrome output on a dedicated thread before waiting for DevTools.
Fail the module-serving step when either test suite fails.
Port the Chrome module initializer tests onto net10.
Measure TestConnectedEvent from the Connected signal, not the pause.
Cancel the WhenAny delays in the lifecycle tests.
Assert that ping completed after shutdown.
Use TheoryData for the file-read failure cases.
Full list: https://github.com/budcribar/RemoteBlazorWebView/compare/10.0.13...66928b247e28dcae5b286883f208c8ae202ed973