Net4x.Runtime.Remoting 2.0.0

Net4x.Runtime.Remoting

A practical System.Runtime.Remoting compatibility layer for .NET Standard 2.0 and .NET 8+.

Keeps the public remoting API, replaces the transport, replaces serialization, and uses generated interface/subclass proxies in place of the CLR's transparent proxies — so an existing .NET Framework remoting application can be recompiled and run on modern .NET.

Quick start

Server

using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

ChannelServices.RegisterChannel(new TcpServerChannel("app", 9000), ensureSecurity: false);

RemotingConfiguration.RegisterWellKnownServiceType(
    typeof(OrderService), "orders.rem", WellKnownObjectMode.Singleton);

Client

ChannelServices.RegisterChannel(new TcpClientChannel(), ensureSecurity: false);

var orders = (IOrderService)RemotingServices.Connect(
    typeof(IOrderService), "tcp://server:9000/orders.rem");

var order = orders.Get(42);      // a real cross-process call

Configuration files keep working too:

RemotingConfiguration.Configure("app.config");   // reads <system.runtime.remoting>

What works

Server-activated objects (Singleton and SingleCall), client-activated objects, server-to-client callbacks and events, ref/out parameters, generic methods, overload resolution by full signature, properties and indexers, exception marshalling with the original type and data, lifetime leases and sponsors, CallContext flow, one-way calls, and <system.runtime.remoting> config parsing.

Serialization honours [Serializable], [NonSerialized], private fields, ISerializable, IObjectReference, IDeserializationCallback, the [On*] callbacks, surrogates, object cycles and shared references — so existing DTOs travel unchanged. BinaryFormatter is not used anywhere; it throws on .NET 9+ and was never an option here.

Two source changes you will need

1. Members on a class contract must be virtual.

The CLR's transparent proxy intercepted every member. A generated proxy is a subclass, and a subclass can only override virtual members — a non-virtual one would run locally on the client, silently returning wrong results. Rather than let that happen, proxy creation fails and names every offending member.

public class OrderService : MarshalByRefObject
{
    public virtual Order Get(int id) { ... }   // add 'virtual'
}

Better still, remote an interface: interface slots are always intercepted, even when the implementing class member is not virtual.

2. Client-activated objects need an explicit factory.

new Foo() was routed through activation by the CLR itself; there is no hook for that off .NET Framework.

var session = RemotingActivator.CreateInstance<Session>(userId);   // was: new Session(userId)

Improvement over classic remoting

Connections are symmetric and multiplexed, so a server calling back into a client-supplied MarshalByRefObject sends the reverse call down the connection the client already opened. The client needs no listening port, and callbacks work through NAT and firewalls. RegisterChannel(new TcpChannel(0)) on a client still succeeds, so existing code is unaffected.

Security

Deserialization defaults to TypeFilterLevel.Low, as on .NET Framework: only safe-listed types are reconstructed, plus assemblies you register with RemotingConfiguration.AllowAssembly. A hard deny list blocks known gadget-chain entry points at every level.

Remoting endpoints are not hardened against hostile callers. Do not expose one to an untrusted network.

Not included

Wire compatibility with unmodified .NET Framework peers (both ends must reference this package), the HTTP/SOAP channels, ContextBoundObject and context attributes, and cross-AppDomain marshalling — see the Net4x.AppDomain package for process-backed application domains.

Proxies are generated with Reflection.Emit, so this package is not compatible with AOT compilation or full trimming.