[dotnet-watch] http transport for mobile by jonathanpeppers · Pull Request #52581 · dotnet/sdk

jonathanpeppers · 2026-01-20T21:48:10Z

Context: #52492

`dotnet watch` for .NET MAUI Scenarios

Overview

This implements dotnet watch / Hot Reload for mobile platforms (Android, iOS), which cannot use the standard named pipe transport. Similar to how web applications already use websockets for reloading CSS and JavaScript, we will use the same model for mobile applications.

Transport Selection

Platform	Transport	Reason
Desktop/Console	Named Pipe	Existing implementation, Fast, local IPC
Android/iOS	WebSocket	Named pipes don't work over the network; `adb reverse` tunnels the connection

dotnet-watch detects WebSocket transport via the HotReloadWebSockets capability:

<ProjectCapability Include="HotReloadWebSockets" />

Mobile workloads (Android, iOS) add this capability to their SDK targets. This allows any workload to opt into WebSocket-based hot reload.

SDK Changes

WebSocket Details

dotnet-watch already has a WebSocket server for web apps: BrowserRefreshServer. This server:

Hosts via Kestrel on https://localhost:<port>
Communicates with JavaScript (aspnetcore-browser-refresh.js) injected into web pages
Sends commands like "refresh CSS", "reload page", "apply Blazor delta"

For mobile, we reuse the Kestrel infrastructure but with a different protocol:

Server	Client	Protocol
`BrowserRefreshServer`	JavaScript in browser	JSON messages for CSS/page refresh
`HotReloadWebSocketServer`	Startup hook on device	Binary delta payloads (same as named pipe)

The mobile server (HotReloadWebSocketServer) extends KestrelWebSocketServer and speaks the same binary protocol as the named pipe transport, just over WebSocket instead.

1. WebSocket Capability Detection

ProjectGraphUtilities.cs checks for the HotReloadWebSockets capability (case-insensitive).

2. MobileAppModel

Creates a MobileHotReloadClient with a WebSocket server instead of named pipes.

3. Environment Variables

dotnet-watch launches the app via:

dotnet run --no-build \
  -e DOTNET_WATCH=1 \
  -e DOTNET_MODIFIABLE_ASSEMBLIES=debug \
  -e DOTNET_WATCH_HOTRELOAD_WEBSOCKET_ENDPOINT=ws://127.0.0.1:<port> \
  -e DOTNET_STARTUP_HOOKS=<path to DeltaApplier.dll>

The port is dynamically assigned (defaults to 0, meaning the OS picks an available port) to avoid conflicts in CI and parallel test scenarios. The DOTNET_WATCH_HOTRELOAD_HTTP_PORT environment variable can override this if a specific port is needed.

These environment variables are passed as @(RuntimeEnvironmentVariable) MSBuild items to the workload. See dotnet-run-for-maui.md for details on dotnet run and environment variables.

Android Workload Changes (Example Integration)

dotnet/android#10770 — RuntimeEnvironmentVariable Support

Enables the Android workload to receive env vars from dotnet run -e:

Adds <ProjectCapability Include="RuntimeEnvironmentVariableSupport" />
Configures @(RuntimeEnvironmentVariable) items, so they will apply to Android.

dotnet/android#10778 — dotnet-watch Integration

Startup Hook: Parses DOTNET_STARTUP_HOOKS, includes the assembly in the app package, rewrites the path to just the assembly name (since the full path doesn't exist on device)
Port Forwarding: Runs adb reverse tcp:<port> tcp:<port> so the device can reach the host's WebSocket server via 127.0.0.1:<port> (port is parsed from the endpoint URL)
Prevents Double Connection: Disables startup hooks in Microsoft.Android.Run (the desktop launcher) so only the mobile app connects
Adds <ProjectCapability Include="HotReloadWebSockets" /> to opt into WebSocket-based hot reload.

Data Flow

Build: dotnet-watch builds the project, detects HotReloadWebSockets capability
Launch: dotnet run -e DOTNET_WATCH_HOTRELOAD_WEBSOCKET_ENDPOINT=ws://127.0.0.1:<port> -e DOTNET_STARTUP_HOOKS=...
Workload: Android build tasks:
- Include the startup hook DLL in the APK
- Set up ADB port forwarding for the dynamically assigned port
- Rewrite env vars for on-device paths
Device: App starts → StartupHook loads → Transport.TryCreate() reads env vars → WebSocketTransport connects to ws://127.0.0.1:<port>
Hot Reload: File change → delta compiled → sent over WebSocket → applied on device

iOS

Similar changes will be made in the iOS workload to opt into WebSocket-based hot reload:

Add <ProjectCapability Include="HotReloadWebSockets" />
Handle startup hooks and port forwarding similar to Android

Dependencies

runtime#123964: [mono] read $DOTNET_STARTUP_HOOKS — needed for Mono runtime to honor startup hooks (temporary workaround via RuntimeHostConfigurationOption)

Context: dotnet/sdk#52492 Context: dotnet/sdk#52581 `dotnet-watch` now runs Android applications via: dotnet watch 🚀 [helloandroid (net10.0-android)] Launched 'D:\src\xamarin-android\bin\Debug\dotnet\dotnet.exe' with arguments 'run --no-build -e DOTNET_WATCH=1 -e DOTNET_WATCH_ITERATION=1 -e DOTNET_MODIFIABLE_ASSEMBLIES=debug -e DOTNET_WATCH_HOTRELOAD_WEBSOCKET_ENDPOINT=ws://localhost:9000 -e DOTNET_STARTUP_HOOKS=D:\src\xamarin-android\bin\Debug\dotnet\sdk\10.0.300-dev\DotnetTools\dotnet-watch\10.0.300-dev\tools\net10.0\any\hotreload\net10.0\Microsoft.Extensions.DotNetDeltaApplier.dll -bl': process id 3356 And so the pieces on Android for this to work are: ~~ Startup Hook Assembly ~~ Parse out the value: <_AndroidHotReloadAgentAssemblyPath>@(RuntimeEnvironmentVariable->WithMetadataValue('Identity', 'DOTNET_STARTUP_HOOKS')->'%(Value)'->Exists())</_AndroidHotReloadAgentAssemblyPath> And verify this assembly is included in the app: <ResolvedFileToPublish Include="$(_AndroidHotReloadAgentAssemblyPath)" /> Then, for Android, we need to patch up `$DOTNET_STARTUP_HOOKS` to be just the assembly name, not the full path: <_AndroidHotReloadAgentAssemblyName>$([System.IO.Path]::GetFileNameWithoutExtension('$(_AndroidHotReloadAgentAssemblyPath)'))</_AndroidHotReloadAgentAssemblyName> ... <RuntimeEnvironmentVariable Include="DOTNET_STARTUP_HOOKS" Value="$(_AndroidHotReloadAgentAssemblyName)" /> ~~ Port Forwarding ~~ A new `_AndroidConfigureAdbReverse` target runs after deploying apps, that does: adb reverse tcp:9000 tcp:9000 I parsed the value out of: <_AndroidWebSocketEndpoint>@(RuntimeEnvironmentVariable->WithMetadataValue('Identity', 'DOTNET_WATCH_HOTRELOAD_WEBSOCKET_ENDPOINT')->'%(Value)')</_AndroidWebSocketEndpoint> <_AndroidWebSocketPort>$([System.Text.RegularExpressions.Regex]::Match('$(_AndroidWebSocketEndpoint)', ':(\d+)').Groups[1].Value)</_AndroidWebSocketPort> ~~ Prevent Startup Hooks in Microsoft.Android.Run ~~ When I was implementing this, I keep seeing *two* clients connect to `dotnet-watch` and I was pulling my hair to figure out why! Then I realized that `Microsoft.Android.Run` was also getting `$DOTNET_STARTUP_HOOKS`, and so we had a desktop process + mobile process both trying to connect! Easiest fix, is to disable startup hook support in `Microsoft.Android.Run`. I reviewed the code in `dotnet run`, and it doesn't seem correct to try to clear the env vars. ~~ Conclusion ~~ With these changes, everything is working! dotnet watch 🔥 C# and Razor changes applied in 23ms. This will depend on getting changes in dotnet/sdk before we merge.

documentation/specs/dotnet-watch-for-maui.md

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs

Copilot

Pull request overview

This PR adds a WebSocket-based hot reload transport to dotnet watch to support mobile scenarios (Android/iOS) where named pipes aren’t viable, selecting the transport via a new HotReloadWebSockets project capability.

Changes:

Add WebSocket transport selection for hot reload (capability detection + mobile app model) and plumb a configurable port via environment options.
Implement WebSocket server/client plumbing for hot reload (watch side Kestrel WebSocket server + agent-side WebSocket transport) while reusing the existing binary delta protocol.
Add a new test project + test coverage validating WebSocket transport selection and hot reload behavior.

Reviewed changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
test/dotnet-watch.Tests/HotReload/MobileHotReloadTests.cs	Adds end-to-end test verifying WebSocket hot reload path is selected and works.
test/TestAssets/TestProjects/WatchMobileApp/WatchMobileApp.csproj	New test asset project that opts into WebSocket transport via `HotReloadWebSockets` capability.
test/TestAssets/TestProjects/WatchMobileApp/Program.cs	New test app used by `dotnet watch` tests to validate hot reload output changes.
test/Microsoft.Extensions.DotNetDeltaApplier.Tests/HotReloadClientTests.cs	Updates agent/client tests to use the new transport abstraction and listener.
src/BuiltInTools/Watch/UI/IReporter.cs	Adds a new debug descriptor to log “Application kind: WebSockets.”
src/BuiltInTools/Watch/Context/EnvironmentVariables.cs	Adds env var names + parsing for the hot reload HTTP port override and WebSocket endpoint name.
src/BuiltInTools/Watch/Context/EnvironmentOptions.cs	Adds `HotReloadHttpPort` option and wires it to environment variable reading.
src/BuiltInTools/Watch/Build/ProjectGraphUtilities.cs	Adds capability-based detection for WebSocket hot reload projects.
src/BuiltInTools/Watch/Build/BuildNames.cs	Introduces `ProjectCapability.HotReloadWebSockets` constant.
src/BuiltInTools/Watch/AppModels/MobileAppModel.cs	New app model that creates a `MobileHotReloadClient` (WebSocket-based).
src/BuiltInTools/Watch/AppModels/HotReloadAppModel.cs	Selects the mobile/WebSocket app model when capability is present.
src/BuiltInTools/HotReloadClient/Web/KestrelWebSocketServer.cs	New Kestrel-hosted WebSocket server base used by mobile hot reload.
src/BuiltInTools/HotReloadClient/MobileHotReloadClient.cs	Implements watch-side WebSocket hot reload client + server coordination.
src/BuiltInTools/HotReloadAgent.Host/Transport.cs	Introduces a transport abstraction for agent communications.
src/BuiltInTools/HotReloadAgent.Host/NamedPipeTransport.cs	Moves named-pipe specifics behind the new `Transport` abstraction.
src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs	Adds WebSocket transport implementation for the agent startup hook.
src/BuiltInTools/HotReloadAgent.Host/Listener.cs	Refactors the listener to work over the new transport abstraction (pipe or WebSocket).
src/BuiltInTools/HotReloadAgent.Host/StartupHook.cs	Switches startup hook connection logic to choose transport from env vars.
src/BuiltInTools/HotReloadAgent.Data/AgentEnvironmentVariables.cs	Adds `DOTNET_WATCH_HOTRELOAD_WEBSOCKET_ENDPOINT` constant.
documentation/specs/dotnet-watch-for-maui.md	Adds a spec describing capability detection, env vars, and workload integration points.

src/BuiltInTools/HotReloadClient/MobileHotReloadClient.cs

documentation/specs/dotnet-watch-for-maui.md

src/BuiltInTools/HotReloadClient/MobileHotReloadClient.cs

src/BuiltInTools/HotReloadAgent.Data/Base64Url.cs

test/Microsoft.Extensions.DotNetDeltaApplier.Tests/HotReloadClientTests.cs

This was using a HTTP listener at first, later switched to WebSockets.

* Now uses `dotnet run -e` environment variables for everything * Now uses web sockets * Adds tests for mobile hot reload

Introduce RSA-based authentication for mobile hot reload WebSocket connections. Adds DOTNET_WATCH_HOTRELOAD_WEBSOCKET_KEY env var and constant, and propagates the server public key to the client. WebSocketTransport now accepts a server public key, encrypts a random 32-byte secret with RSA-OAEP-SHA256, and sends it as a URL-safe Base64 subprotocol token. HotReloadWebSocketServer uses SharedSecretProvider to expose the public key and to decrypt/validate the incoming secret, rejecting connections with missing/invalid secrets. Also adds a Base64Url helper for URL-safe Base64 encoding/decoding and updates documentation and cleanup to dispose the shared secret provider.

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs

tmat · 2026-02-13T19:29:04Z

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs

+        var encrypted = rsa.Encrypt(secret, RSAEncryptionPadding.OaepSHA256);
+
+        // Convert to URL-safe Base64 for WebSocket subprotocol header
+        return Base64Url.EncodeToString(encrypted);


Can we use Convert.ToBase64String?

It needs to use System.Buffers.Text.Base64Url.EncodeToString() because of +, /, and trailing =.

I called the BCL for .NET 8+ where they added this API, but I had to write a version for netstandard2.0.

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs

tmat · 2026-02-13T19:43:19Z

src/BuiltInTools/Watch/Context/EnvironmentVariables.cs

+    /// Port for HTTP hot reload communication. Used for projects with the HotReloadWebSockets capability.
+    /// Mobile workloads (Android, iOS) add this capability. Defaults to 0 (auto-assign) if not specified.
+    /// </summary>
+    public static int HotReloadHttpPort => ReadInt(Names.DotNetWatchHotReloadHttpPort) ?? 0;


We need two ports - one for HTTP and another one for HTTPs, right? Otherwise, they're gonna collide.

We have similar problem with AutoReloadWebSocketPort: #52959

Let's call this variable AgentWebSocketPort (and AgentWebSocketSecurePort for wss).

(A better name for AutoReloadWebSocketPort would be BrowserWebSocketPort. I'll rename it in #52959.).

src/BuiltInTools/Watch/Build/ProjectGraphUtilities.cs

tmat · 2026-02-13T20:00:32Z

src/BuiltInTools/HotReloadClient/MobileHotReloadClient.cs

+/// 
+/// Server-side implementation using Kestrel + WebSockets, extends KestrelWebSocketServer.
+/// </summary>
+internal sealed class MobileHotReloadClient : HotReloadClient


Most of the code, other than sending/receiving messages is now the same as DefaultHotReloadClient.

I think it'd make sense to define similar Transport abstraction as we have in the agent and use DefaultHotReloadClient for both cases. It would create named pipe/web socket transport layer depending on given parameters.

Addressed in 7798648, 🤞 the tests still pass.

It does look a lot cleaner this way.

src/BuiltInTools/HotReloadClient/MobileHotReloadClient.cs

src/BuiltInTools/HotReloadClient/Web/KestrelWebSocketServer.cs

tmat · 2026-02-13T20:12:37Z

src/BuiltInTools/HotReloadClient/MobileHotReloadClient.cs

+
+        public async ValueTask StartServerAsync(string hostName, int port, CancellationToken cancellationToken)
+        {
+            await base.StartServerAsync(hostName, port, useTls: false, cancellationToken);


Shouldn't we enable HTTPs?

I'd move IsTlsSupportedAsync, GetServerUrls and the body of CreateAndStartHostAsync from BowserRefreshServer to KestrelWebSocketServer, create an instance of KestrelWebSocketServer in BowserRefreshServer and delegate the implementation to it.

Addressed this one in: c0f5f7b

…ientTransport` abstraction Addressing: dotnet#52581 (comment)

Address: https://github.com/dotnet/sdk/pull/52581/changes#r2805711141

Address: dotnet#52581 (comment)

tmat · 2026-02-13T22:51:36Z

src/BuiltInTools/HotReloadAgent.Host/Transport.cs

        {
-            log($"{AgentEnvironmentVariables.DotNetWatchHotReloadWebSocketEndpoint}={webSocketEndpoint}");
+            if (!Uri.TryCreate(webSocketEndpoint, UriKind.Absolute, out var uri) ||
+                (uri.Scheme != "ws" && uri.Scheme != "wss"))


Nit: could be uri.Scheme is not ("ws" or "wss")

tmat · 2026-02-13T23:01:33Z

src/BuiltInTools/HotReloadClient/NamedPipeClientTransport.cs

+
+    public override async Task<string> WaitForConnectionAsync(CancellationToken cancellationToken)
+    {
+#if NET


We can move creation of the pip[e to the constructor and then remove all _pipe != null checks in the type.

tmat · 2026-02-13T23:06:44Z

src/BuiltInTools/HotReloadClient/NamedPipeClientTransport.cs

+        await _pipe.WaitForConnectionAsync(cancellationToken);
+
+        // When the client connects, the first payload it sends is the initialization payload which includes the apply capabilities.
+        var capabilities = (await ClientInitializationResponse.ReadAsync(_pipe, cancellationToken)).Capabilities;


I'd return Stream? from this method and moved reading the initialization message to the caller, to avoid leaking the protocol into the transport layer.

Actually, can we just create the connection here and then call ReadAsync to read the initial message in the caller instead?

tmat · 2026-02-13T23:15:07Z

src/BuiltInTools/HotReloadClient/NamedPipeClientTransport.cs

+
+        logger.LogDebug("Waiting for application to connect to pipe {NamedPipeName}.", _namedPipeName);
+
+        await _pipe.WaitForConnectionAsync(cancellationToken);


I think we need to keep the try-catch around this call. The process may die while we waiting for the connection and the pipe may be disposed.

catch (Exception e) when (e is not OperationCanceledException) { ReportPipeReadException(e, "capabilities", cancellationToken); return null; }

tmat · 2026-02-13T23:26:24Z

src/BuiltInTools/HotReloadClient/DefaultHotReloadClient.cs

                applyOperationCancellationToken);
        }

+        private async Task ListenForResponsesAsync(CancellationToken cancellationToken)


Nit: Would you mind moving this before GetCapabilitiesTask() method, so that it's easier to see the differences and merge any conflicts?

tmat · 2026-02-13T23:33:19Z

src/BuiltInTools/HotReloadClient/Web/KestrelWebSocketServer.cs

    /// <param name="useTls">Whether to enable HTTPS</param>
    /// <param name="cancellationToken">Cancellation token</param>
-    protected async ValueTask StartServerAsync(string hostName = "localhost", int port = 0, bool useTls = false, CancellationToken cancellationToken = default)
+    public async ValueTask StartServerAsync(string hostName, int port, bool useTls, CancellationToken cancellationToken)


This needs two ports to avoid collision (ws and wss)

You can replace useTls with int? securePort.

tmat · 2026-02-13T23:41:16Z

src/BuiltInTools/HotReloadClient/Web/KestrelWebSocketServer.cs

    /// <summary>
    /// Converts an HTTP(S) URL to a WebSocket URL.
    /// </summary>
    protected virtual string ConvertToWebSocketUrl(string httpUrl)


Doesn't need to be virtual

tmat · 2026-02-13T23:44:22Z

src/BuiltInTools/HotReloadClient/Web/KestrelWebSocketServer.cs

    /// <summary>
    /// Helper to accept a WebSocket connection.
    /// </summary>
    protected async ValueTask<WebSocket?> AcceptWebSocketAsync(HttpContext context, string? subProtocol = null)


Only called from AgentWebSocketServer.HandleRequestAsync. We can inline it.

tmat · 2026-02-13T23:46:44Z

src/BuiltInTools/HotReloadClient/Web/KestrelWebSocketServer.cs

    /// Handles incoming HTTP requests. Override to implement WebSocket logic.
    /// </summary>
-    protected abstract Task HandleRequestAsync(HttpContext context);
+    protected virtual Task HandleRequestAsync(HttpContext context)


Since this is the only virtual method and it delegates to _requestHandler we can make this class sealed and pass delegate from AgentWebSocketServer (i.e. not inherit AgentWebSocketServer from KestrelWebSocketServer).

Then can potentially also merge AgentWebSocketServer into WebSocketClientTransport

tmat · 2026-02-13T23:51:51Z

src/BuiltInTools/HotReloadClient/AgentWebSocketServer.cs

+        string? decryptedSecret;
+        try
+        {
+            decryptedSecret = _sharedSecretProvider.DecryptSecret(Base64Url.DecodeToStandardBase64(subProtocol));


We're using WebUtility.UrlDecode in AbstractBrowserRefreshServer.OnBrowserConnected to decode the secret

tmat · 2026-02-13T23:52:58Z

src/BuiltInTools/HotReloadClient/AgentWebSocketServer.cs

+            return;
+        }
+
+        if (string.IsNullOrEmpty(decryptedSecret))


We already checked string.IsNullOrEmpty(subProtocol) above, the decrypted secret shouldn't be empty, right?

tmat · 2026-02-13T23:54:21Z

src/BuiltInTools/HotReloadClient/AgentWebSocketServer.cs

+    protected override async Task HandleRequestAsync(HttpContext context)
+    {
+        // Validate the shared secret from the subprotocol
+        if (context.WebSockets.WebSocketRequestedProtocols is not [var subProtocol] || string.IsNullOrEmpty(subProtocol))


Wouldn't subProtocol ne null for non-secure connection?

tmat · 2026-02-14T00:09:46Z

src/BuiltInTools/Watch/AppModels/MobileAppModel.cs

        // passed via `dotnet run -e` as @(RuntimeEnvironmentVariable) items.
-        => new(new HotReloadClients(new MobileHotReloadClient(clientLogger, agentLogger, context.EnvironmentOptions.HotReloadHttpPort, GetStartupHookPath(project)), browserRefreshServer: null));
+        => new(new HotReloadClients(
+            new DefaultHotReloadClient(clientLogger, agentLogger, GetStartupHookPath(project), enableStaticAssetUpdates: false,


enableStaticAssetUpdates should be true, no? Don't we want to send over CSS updates? The same as Windows MAUI app.

tmat · 2026-02-14T00:13:43Z

test/dotnet-watch.Tests/HotReload/MobileHotReloadTests.cs

+
+        App.Start(testAsset, []);
+
+        await App.WaitForOutputLineContaining("Started");


We should use App.WaitUntileOutputContains to avoid race conditions between the process output and watch output.

You can use await App.WaitUntileOutputContains instead of App.AssertOutputContains as well, unless you particularly care about the order in which the messages appear.

jonathanpeppers mentioned this pull request Jan 20, 2026

[Epic] vibe-coding .NET MAUI apps works out of the box dotnet/maui#32967

Open

51 tasks

build-analysis bot mentioned this pull request Jan 22, 2026

dotnet-watch tests failing #40006

Open

This was referenced Feb 5, 2026

Template Engine SSL Connection Issue #51574

Open

Known Test Repository Issue Sometimes Misses Test Failures dotnet/dnceng#6411

Open

Template engine tests hitting known parallelism issue in GetVisualStudioInstances #44878

Open

jonathanpeppers mentioned this pull request Feb 6, 2026

[xabt] dotnet watch support, based on env vars dotnet/android#10778

Draft

rolfbjarne reviewed Feb 11, 2026

View reviewed changes

documentation/specs/dotnet-watch-for-maui.md Outdated Show resolved Hide resolved

jonathanpeppers marked this pull request as ready for review February 11, 2026 20:32

jonathanpeppers requested review from a team and tmat as code owners February 11, 2026 20:32

jonathanpeppers requested review from MichaelSimons and Copilot February 11, 2026 20:32

Copilot started reviewing on behalf of jonathanpeppers February 11, 2026 20:33 View session

jonathanpeppers commented Feb 11, 2026

View reviewed changes

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs Outdated Show resolved Hide resolved

Copilot AI reviewed Feb 11, 2026

View reviewed changes

simonrozsival reviewed Feb 12, 2026

View reviewed changes

src/BuiltInTools/HotReloadAgent.Data/Base64Url.cs Show resolved Hide resolved

simonrozsival reviewed Feb 12, 2026

View reviewed changes

test/Microsoft.Extensions.DotNetDeltaApplier.Tests/HotReloadClientTests.cs Show resolved Hide resolved

simonrozsival approved these changes Feb 12, 2026

View reviewed changes

jonathanpeppers and others added 3 commits February 13, 2026 07:50

Initial implementation / spike

2366820

This was using a HTTP listener at first, later switched to WebSockets.

Transport abstraction

64e7077

MobileAppModel

81ccc56

jonathanpeppers force-pushed the dev/peppers/watch-http-transport branch from 9001e8b to 41e4074 Compare February 13, 2026 13:58

jonathanpeppers added 2 commits February 13, 2026 07:59

Updated implementation

2721719

* Now uses `dotnet run -e` environment variables for everything * Now uses web sockets * Adds tests for mobile hot reload

jonathanpeppers force-pushed the dev/peppers/watch-http-transport branch from 41e4074 to 9af2d80 Compare February 13, 2026 13:59

tmat reviewed Feb 13, 2026

View reviewed changes

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs Outdated Show resolved Hide resolved

tmat reviewed Feb 13, 2026

View reviewed changes

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs Outdated Show resolved Hide resolved

Address code review comments

31f6a44

tmat reviewed Feb 13, 2026

View reviewed changes

src/BuiltInTools/HotReloadAgent.Host/WebSocketTransport.cs Outdated Show resolved Hide resolved

tmat reviewed Feb 13, 2026

View reviewed changes

src/BuiltInTools/Watch/Build/ProjectGraphUtilities.cs Outdated Show resolved Hide resolved

tmat reviewed Feb 13, 2026

View reviewed changes

src/BuiltInTools/HotReloadClient/MobileHotReloadClient.cs Outdated Show resolved Hide resolved

tmat reviewed Feb 13, 2026

View reviewed changes

src/BuiltInTools/HotReloadClient/Web/KestrelWebSocketServer.cs Outdated Show resolved Hide resolved

tmat reviewed Feb 13, 2026

View reviewed changes

tmat requested changes Feb 13, 2026

View reviewed changes

jonathanpeppers added 4 commits February 13, 2026 14:47

Code Review Feedback - Part 1

3eae972

Unify MobileHotReloadClient and DefaultHotReloadClient behind `Cl…

7798648

…ientTransport` abstraction Addressing: dotnet#52581 (comment)

Reuse MemoryStream buffers

af2ea2e

Address: https://github.com/dotnet/sdk/pull/52581/changes#r2805711141

Refactor KestrelWebSocketServer for composition

c0f5f7b

Address: dotnet#52581 (comment)

tmat reviewed Feb 13, 2026

View reviewed changes

tmat reviewed Feb 14, 2026

View reviewed changes


		logger.LogDebug("Waiting for application to connect to pipe {NamedPipeName}.", _namedPipeName);

		await _pipe.WaitForConnectionAsync(cancellationToken);


		App.Start(testAsset, []);

		await App.WaitForOutputLineContaining("Started");

Conversation

jonathanpeppers commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

dotnet watch for .NET MAUI Scenarios

Overview

Transport Selection

SDK Changes

WebSocket Details

1. WebSocket Capability Detection

2. MobileAppModel

3. Environment Variables

Android Workload Changes (Example Integration)

dotnet/android#10770 — RuntimeEnvironmentVariable Support

dotnet/android#10778 — dotnet-watch Integration

Data Flow

iOS

Dependencies

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmat Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tmat Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmat Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmat Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonathanpeppers commented Jan 20, 2026 •

edited

Loading

`dotnet watch` for .NET MAUI Scenarios

tmat Feb 13, 2026 •

edited

Loading

tmat Feb 13, 2026 •

edited

Loading

tmat Feb 13, 2026 •

edited

Loading

tmat Feb 13, 2026 •

edited

Loading

tmat Feb 13, 2026 •

edited

Loading

tmat Feb 14, 2026 •

edited

Loading