What is WitRPC?
WitRPC (package family OutWit.Communication) is a remote procedure call framework for modern .NET. It connects components of a distributed system: separate processes on one machine, services on a local network, or applications talking across the internet. Communication is full-duplex, so calls and notifications flow in both directions over a single connection.
The programming model is simple to state: you define a service contract as an ordinary C# interface, and the framework handles serialization, transport, security, and error handling underneath. The client receives a proxy object that implements the interface; calling a method on the proxy executes it on the server, and events raised on the server arrive at the client as ordinary C# events. Working with a remote service feels like working with a local object.
WitRPC runs on .NET 6 through .NET 10, on Windows, Linux, and macOS, and in Blazor WebAssembly.
The interface-driven model
The design follows the productivity of WCF's programming model. In WCF, a service was defined by an interface, and clients called it through generated proxies with full compile-time checking. WitRPC carries that idea into cross-platform .NET without the configuration weight that came with WCF.
A shared interface is the single source of truth for the API. When a client connects, it obtains a dynamic proxy implementing that interface. Method calls on the proxy become remote calls; server-side events propagate back to client-side subscribers. Since both sides compile against the same interface, renaming a method or changing a signature is caught by the compiler, and refactoring tools work across the client-server boundary. Frameworks that dispatch calls by string name give this safety up; here it comes with the model.
For environments that forbid runtime code generation, such as Blazor WebAssembly with AOT compilation, WitRPC generates static proxies at build time. The programming model stays the same.
Key features
Interface-driven contracts. Services are standard C# interfaces. All communication is strongly typed, with compile-time checking and full IDE support for navigation and refactoring.
Full-duplex communication. Servers invoke client-side events and callbacks over the same connection clients use for calls. Real-time updates need no polling and no separate push channel.
Pluggable transports. Memory-mapped files and named pipes for fast local IPC; TCP (with TLS) and WebSockets for the network; REST for interoperability with non-.NET clients. Switching transports leaves service code untouched.
Pluggable serializers. JSON by default, with MessagePack, MemoryPack, and ProtoBuf available for compact payloads and speed. Changing the serializer is a one-line configuration change.
Built-in security. End-to-end encryption with an RSA/AES handshake, token-based authorization, and a BouncyCastle-based encryption option that works in Blazor WebAssembly. See Security & Authentication →.
Composite services. One server can host several service interfaces at once, and a client can request a proxy for any of them over a single connection.
Resilience. Automatic reconnection with configurable retry strategies, per-call retry policies, and ASP.NET Core health check integration. See Resilience & Health Checks →.
Service discovery. Servers can announce themselves over UDP multicast, and clients can find them on the local network without preconfigured addresses.
Host/Agent IPC model. The
OutWit.InterProcessextension manages child processes: launching, monitoring, and shutting down agent processes that host WitRPC services. See IPC: Host/Agent Model →.Extensibility. Default transports, serializers, encryption, and authorization can each be replaced with custom implementations.
Typical use cases
Inter-process communication on one machine. Split a large application into isolated processes and connect them as if they were one: a 64-bit host offloading work to a 32-bit helper that wraps a legacy library, a plugin sandboxed in its own process, an unstable component kept away from the main application. Calls and events travel over named pipes or memory-mapped files with minimal latency.
Real-time client updates. In dashboards, monitoring tools, chat, or anything where the server pushes state to clients, a client subscribes to events on its service proxy and the server triggers them as things happen. This replaces polling and hand-wired push channels with a typed contract.
Services across a network. A .NET service exposes a WitRPC interface over TCP or WebSocket; other services or Blazor clients call it directly, with TLS and token authorization where the network is untrusted. The result is comparable to what gRPC provides for .NET-to-.NET cases, without proto schemas or code generation steps.
Modernizing WCF solutions. Applications built on WCF can reimplement their service contracts as WitRPC interfaces and keep the familiar strongly-typed model, minus the XML configuration and IIS hosting. WitRPC servers start with a few lines of code and run cross-platform, which opens formerly Windows-only systems to Linux and cloud environments.
How WitRPC compares
WCF. WitRPC inherits the interface-based contract and automatic proxy from WCF's RPC model, and drops the configuration burden. It is code-first, works out of the box on modern .NET, and needs no bindings or config files. If WCF's approach suited you and the platform did not, this is the same experience with far less friction.
gRPC. gRPC is polyglot and defines contracts in Protocol Buffers; WitRPC is .NET-native and defines contracts in C#. With WitRPC there is no separate schema file and no generation step, and subscribing to a server event is one line of code rather than a streaming pattern. gRPC remains the right choice when clients span multiple languages. When both sides are .NET, WitRPC offers the more direct programming model. A detailed measured comparison is in Comparing RPC Frameworks in .NET Applications →.
SignalR. SignalR's hub model typically invokes methods by name, which trades compile-time safety for flexibility and broad client support. WitRPC enforces a strict interface contract on both sides, supports return values and multiple services per connection, and runs anywhere .NET runs rather than centering on web scenarios. SignalR keeps the advantage for broadcasting to very large numbers of clients, including JavaScript ones.
Next steps
The Quick Start → builds a working client-server pair in a few minutes: a service with methods and events, a server hosting it, and a client calling it through a proxy.