Introduction

MarshalByRefObject exists so an object can stay in one .NET application domain while callers in another domain interact with it through a proxy. Its major use was cross-boundary communication in classic .NET Framework scenarios such as .NET Remoting and AppDomain isolation.

The Core Idea: Pass a Proxy Instead of a Copy

By default, objects crossing an AppDomain boundary had to be serialized and copied. That is called marshalling by value. MarshalByRefObject changes the behavior: the object stays where it was created, and the caller receives a transparent proxy that forwards method calls back to the original instance.

That distinction matters when:

• the object holds mutable state that should not be copied
• the object wraps resources such as file handles or sockets
• the object is expensive or impossible to serialize cleanly

So the class was not about performance alone. It was about preserving identity and behavior across boundaries.

A Classic .NET Framework Example

The pattern was common in old AppDomain-based code. A type derived from MarshalByRefObject could be created in another domain and then used almost like a local object.

1using System;
2
3public class Counter : MarshalByRefObject
4{
5    private int _value;
6
7    public int Increment()
8    {
9        _value++;
10        return _value;
11    }
12}
13
14// .NET Framework example
15var domain = AppDomain.CreateDomain("WorkerDomain");
16
17var counter = (Counter)domain.CreateInstanceAndUnwrap(
18    typeof(Counter).Assembly.FullName,
19    typeof(Counter).FullName
20);
21
22Console.WriteLine(counter.Increment()); // 1
23Console.WriteLine(counter.Increment()); // 2

The Counter object lives in WorkerDomain, but the calling code can still invoke methods on it. Under the hood, the runtime routes the call through a proxy.

Why Not Just Serialize the Object?

Marshalling by value is fine for plain data. It is a poor fit for live service objects. If you copy a service object into another AppDomain, you no longer have one shared instance. You have two separate objects with independent state.

MarshalByRefObject preserved the idea of "one real object, many callers." That was the main reason it existed.

A good rule of thumb in classic .NET Framework was:

• use serializable objects for data transfer
• use MarshalByRefObject for behavior and shared state

Remoting, AppDomains, and Why This Is Mostly Legacy Now

This topic is historically important, but it is also legacy-heavy. The big users of MarshalByRefObject were .NET Remoting and AppDomain isolation in the .NET Framework era. Modern .NET changed the picture significantly:

• .NET Remoting is not part of modern .NET
• AppDomain-based isolation is much less central than it once was
• process boundaries are now more commonly handled with gRPC, HTTP APIs, named pipes, or message brokers

So if you see MarshalByRefObject in older code, it is usually there because the application was designed around remoting or AppDomain boundaries. In new code, it is not a common first choice.

A Second Use Case: Plugin or Host Isolation

Another historic use case was loading plugins into separate AppDomains so the host could isolate failures or unload code more cleanly. The plugin-facing service object would derive from MarshalByRefObject, letting the host and plugin communicate without cloning the service state every time.

That pattern made sense in old extensibility systems, but modern plugin architectures often solve the problem differently.

Common Pitfalls

The first pitfall is thinking MarshalByRefObject makes an object "shared everywhere" automatically. It only matters when the runtime is actually crossing a remoting or AppDomain boundary.

Another mistake is using it in modern .NET code without realizing that most of the surrounding infrastructure is legacy. In current applications, newer IPC and service boundaries are usually the better fit.

Old remoting code also had lifetime and leasing behavior that could surprise developers. If the proxy suddenly stopped working, the issue was sometimes the remote lifetime policy rather than the business logic itself.

Summary

• The main use of MarshalByRefObject was letting callers interact with an object across AppDomain or remoting boundaries through a proxy.
• It preserves one real object instance instead of copying the object by serialization.
• It was especially useful for remote services, shared mutable state, and plugin-host communication in classic .NET Framework.
• The type is mostly relevant in legacy code because .NET Remoting and AppDomain-heavy designs are no longer central in modern .NET.
• In new systems, other communication approaches such as HTTP, gRPC, or message-based IPC are usually preferred.