`dotnet-watch` support for mobile

[jonathanpeppers]

I have an example working end-to-end, with changes to the dotnet/sdk + an MSBuild target added to a dotnet new android sample project.

Requirements

A list of things needed:

• Pass the path to Microsoft.Extensions.DotNetDeltaApplier.dll during the build
  • On desktop, this works if you dotnet-watch a local process, $DOTNET_STARTUP_HOOKS is used and it can load the file on disk. For mobile we need to "deploy" the assembly. This can simply be added to the @(Reference) item group.

Example:

<PropertyGroup>
  <_DotNetWatchToolPath>$([MSBuild]::NormalizePath('$(MSBuildSDKsPath)', '..', 'DotnetTools', 'dotnet-watch', '$(NETCoreSdkVersion)', 'tools', 'net10.0', 'any'))</_DotNetWatchToolPath>  
  <!-- D:\src\dotnet\sdk\artifacts\bin\redist\Debug\dotnet-installer\sdk\10.0.200-dev\DotnetTools\dotnet-watch\10.0.200-dev\tools\net10.0\any\hotreload\net10.0\Microsoft.Extensions.DotNetDeltaApplier.dll -->
  <_HotReloadAgentPath>$(_DotNetWatchToolPath)\hotreload\net10.0\Microsoft.Extensions.DotNetDeltaApplier.dll</_HotReloadAgentPath>
</PropertyGroup>
<ItemGroup>
  <Reference Include="$(_HotReloadAgentPath)" />
</ItemGroup>

• Environment variables
  • Env vars like $DOTNET_STARTUP_HOOKS needs to be baked into mobile applications, as there isn't a way to set them outside of Android's sandbox.
  • We could change either the .NET SDK or Android/iOS workloads to apply these via existing MSBuild item groups.

Example:

<ItemGroup>
  <!-- either one of these two -->
  <RuntimeHostConfigurationOption Include="STARTUP_HOOKS" Value="Microsoft.Extensions.DotNetDeltaApplier" />
  <AndroidEnvironment Include="DOTNET_STARTUP_HOOKS" Value="Microsoft.Extensions.DotNetDeltaApplier" />
  <!-- other env vars -->
  <AndroidEnvironment Include="DOTNET_WATCH_HOTRELOAD_HTTP_ENDPOINT" Value="https://localhost:$(DotNetWatchHotReloadHttpPort)/hotreload/" />
  <AndroidEnvironment Include="HOTRELOAD_DELTA_CLIENT_LOG_MESSAGES" Value="[HotReload]" />
</ItemGroup>

• New transport
  • Named pipes are used on desktop, I had dotnet-watch open an HttpListener and the application connects back to dotnet-watch. Android uses the adb reverse command that allows both emulators/devices to talk to dotnet-watch.
  • We would need to pass a port number to MSBuild, to call adb reverse (mlaunch on iOS). This could be a standard property we add to Android/iOS workloads. I ran the command right after ComputeRunArguments MSBuild target in my sample.
  • We would need to pass a value to the build to set an env var like $DOTNET_WATCH_HOTRELOAD_HTTP_ENDPOINT, that allows Microsoft.Extensions.DotNetDeltaApplier.dll to connect to dotnet-watch.

iOS

So far, everything I've seen to get Android to work, also applies to iOS. We should be able to get both platforms working with these changes.

[tmat]

I think we want to implement it like so:

Android and iOS SDKs will define target DeployHotReloadAgentConfiguration that
a) copies the dll located at path specified by msbuild property DotNetHotReloadAgentStartupHook
b) adds env var DOTNET_STARTUP_HOOKS with value $(DotNetHotReloadAgentStartupHook) to the device environment
c) adds additional variables listed in DotNetHotReloadAgentEnvironment property to device environment
(e.g. DOTNET_WATCH_HOTRELOAD_HTTP_ENDPOINT=<Url>;HOTRELOAD_DELTA_CLIENT_LOG_MESSAGES=...)

dotnet-watch/IDE will check if the project has DeployHotReloadAgentConfiguration target. If so, it will evaluate it when Hot Reload starts with global properties DotNetHotReloadAgentStartupHook and DotNetHotReloadAgentEnvironment set.

[rolfbjarne]

a) copies the dll located at path specified by msbuild property DotNetHotReloadAgentStartupHook

Where to specifically?

Next to all the other assemblies? Then it has to be done during the build (for two reasons: the assembly location on a physical iOS device is read-only, and the entire app bundle is also signed, so even if we could add a file in the app bundle, it would invalidate the signature)

Some other place on the device (temporary directory, etc.)?

If so, the DeployHotReloadAgentConfiguration target would have to return the actual location of the copied assembly (so that the location could be passed to the app when the app is launched)

[jonathanpeppers]

I found that $DOTNET_STARTUP_HOOKS can be set to a full path or just an assembly name. Android, I had things working just using the assembly name, but we could do this differently for iOS.

The iOS workload's DeployHotReloadAgentConfiguration target could set things up appropriately?

[jonathanpeppers]

So, in implementing the plan above, I found a problem...

• dotnet-watch runs DeployHotReloadAgentConfiguration
• Microsoft.Extensions.DotNetDeltaApplier.dll is deployed
• dotnet-watch then runs dotnet-run, which runs DeployToDevice without $(DotNetHotReloadAgentStartupHook)
• Things are deployed again, and you get:

Remove redundant file files/.__override__/arm64-v8a/Microsoft.Extensions.DotNetDeltaApplier.dll

So, here is a modified plan, where we would not add a new target at all:

• dotnet watch passes in env vars to dotnet run:
  • $DOTNET_STARTUP_HOOKS plus any others
  • These are passed via: dotnet run -e DOTNET_WATCH=1 -e DOTNET_WATCH_ITERATION=1 -e DOTNET_STARTUP_HOOKS=...
• dotnet run passes these env vars to the DeployToDevice target as:
  • @(DotNetEnvironment) item group
• Mobile workloads iOS/Android just use the DeployToDevice target to setup Hot Reload as before.

[rolfbjarne]

• Mobile workloads iOS/Android just use the DeployToDevice target to setup Hot Reload as before.

If we want the Microsoft.Extensions.DotNetDeltaApplier.dll assembly to be located together with all the assemblies in the app bundle, we'll have to know during the build, because the app location is read-only when the app is deployed (because the app is signed). This would also be the easiest to implement on our side, by far.

Alternatively, I believe we can put the assembly in some other directory on the device during the deploy (temporary directory, some kind of app-local storage, etc.), but then we'll have to return the path to the location (because it wouldn't necessarily be a stable location we can compute), so that the corresponding environment variable can be set to the correct location for the assembly to be loaded. Alternatively we can bake in knowledge about the environment variable and modify it on the fly to point to the right location.

dotnet run passes these env vars to the DeployToDevice target as:

• @(DotNetEnvironment) item group

Does the @(DotNetEnvironment) item group already exist? Because this can be implemented separately already if that's the case.