Core.AppDomain.Host 2.0.0.26263

Net4x.AppDomain.Host

The program that is a child application domain.

This is not a standalone package. It is built as a net8.0 executable and shipped inside the Net4x.AppDomain package under tools/net8.0/, where HostLocator finds it. One process is started per domain; you never reference this assembly or invoke it yourself.

parent process                          this program (one per domain)
──────────────────────────────          ────────────────────────────────────────
AppDomain.CurrentDomain
  .CreateChildDomain("worker")
        │  dotnet exec Net4x.AppDomain.Host.dll --name worker --base … --parent-pid …
        │                                       │
        │  <── stdout: "READY <port> <uri>"     ├─ TcpServerChannel(0) on 127.0.0.1
        │                                       ├─ publishes IDomainController
        │                                       ├─ assembly resolver rooted at --base
        │                                       └─ watchdog on the parent process
        ▼
ChildAppDomain ───── remoting ─────────>  DomainController

Command line

Arguments are passed as quoted pairs. A trailing backslash in a path is doubled before quoting — otherwise "C:\dir\" would escape its own closing quote on Windows and swallow every argument after it.

The startup handshake

The host prints exactly one line to stdout when it is ready to serve:

READY <port> <controllerUri>

The child picks its own port (binding 0 and reporting back), which removes the bind race a parent-chosen port would have. The parent reads that line with a timeout, then connects to tcp://127.0.0.1:<port>/<controllerUri>.

Two consequences worth respecting when changing this program:

• stdout is a protocol. Anything this host wants to say goes to stderr. A stray Console.WriteLine before the handshake would be parsed as the READY line, or would delay it past the parent's timeout. Output written by hosted code is fine — it is forwarded to the parent's ChildAppDomain.OutputReceived after the handshake completes.
• A failure before READY must be loud. The parent captures everything the child wrote and includes it in the exception, because "the domain would not start" is otherwise miserable to diagnose.

What it does

• Publishes one well-known object, IDomainController, at an unguessable uri. Everything else the parent reaches is a reference the controller handed back.
• Resolves assemblies from ApplicationBase, then PrivateBinPath, then the host's own directory, and finally asks the parent — which can answer with a path or with raw bytes, since an Assembly cannot cross a process boundary.
• Forwards events: unhandled exceptions (as text, since an arbitrary exception type may not be loadable in the parent) and assembly loads (as full names, since AssemblyName.GetObjectData throws PlatformNotSupportedException off .NET Framework).
• Watches the parent and exits when it disappears, so a crashed parent leaves no orphan processes holding ports. A polled process handle is used rather than a Windows job object, so the behaviour is the same on Linux and macOS.
• Keeps created MarshalByRefObjects alive, since the remoting layer's proxy table holds only weak references and a collection would otherwise take a live worker away mid-session.

Security

The channel binds 127.0.0.1 only, so a domain is never reachable off the machine, and the controller uri carries 128 bits of entropy delivered over the child's stdout.

That is hardening, not a security boundary: another process running as the same user can read the child's output or attach a debugger. Domains isolate code against faults, not against malice.

Building

Built automatically by Net4x.AppDomain.Tests and packed into Net4x.AppDomain. To build alone:

dotnet build Net4x.AppDomain.Host\Net4x.AppDomain.Host.csproj -c Release