If you've ever written a .NET remoting channel you'd have come across the ServerProcessing.Async value. This value should indicate that a server object is handling a message asynchronously. There's then a some additional infrastructure for handling the real message reply later when it becomes available (through the use of IServerChannelSinkStack).
Up until now this value has been largely unused. In standard remoting it is never returned (it is possibly used in CrossAppDomain calls). I say up until now because I have now successfully made use of it!
For my PhD I needed to provide a method for application programmers to create asynchronous implementation of methods. I've based this off the undocumented ASP.NET web service async implementation model which is something like this:
int Foo(string value)
becomes
IAsyncResult BeginFoo(string value);
int EndFoo(IAsyncResult ar);
As you can see the implementation of Foo will be split across two methods - BeginFoo and EndFoo. When BeginFoo returns it supplies an IAsyncResult which will be triggered by some third party (perhaps another method call to the same object, or the result of an IO becoming available). The framework is then responsible for calling EndFoo. Clients should be hidden from the details - in fact they simply call Foo - the BeginFoo/EndFoo stuff all happens on the server side.
Currently there's no nice way of providing the Foo signature to clients so a dummy Foo implementation must be required (something like just throwing NotImplementedException is fine since it's never called). ASP.NET gets around this by generating appropriate WSDL when it finds two methods that match this BeginFoo/EndFoo pattern.
Of course, even though I got to make use of the Async return value I found that some of the supporting clases required a bit of massaging to get working properly. This doesn't surprise me since I don't think this is ever used in standard remoting...