Recently had the chance to dig into remoting in a bit more detail (for the Bulk Mail app I've mentioned before). I have to say, it's both more difficult and a lot easier than I imagined!
Having to modify my class to allow use from a remoting client was a little wierd; I wanted to use SingleCall mode - with a simple response to keep performance up, unfortunately this has led to quite a radical reworking of my main Engine class (and subsequent bug-fixing...it wasn't that tight in the first place). The actual set up of remoting is however amazingly easy, letting me simple switch from local to remoting versions with a simple bit of config...e.g.
<system.runtime.remoting>
<application>
<client>
<wellknown type="SurgeEngine.EngineFacade, SurgeEngine" url="tcp://localhost:9080/SurgeEngine"/>
<channels ref="tcp" port="0">
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
</channels>
</client>
</application>
</system.runtime.remoting>
Oh, I did use a Facade pattern to help reduce the type and number of changes I had to make to my core engine (specifically to reduce the amount of thread-handling code in the core engine...
One oddity I did come across though was trying to use remoting from an ASP.NET site - which is what this app was doing, acting as a web-service proxy to another remoting server on the same box (simplifies things for non-.NET clients using the app...config etc...). No idea where I found it but this code in my Global.asax.cs helped a lot:
protected void Application_Start(Object sender, EventArgs e)
{
string configFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
RemotingConfiguration.Configure(configFile);
}
All this really does is aid the app in identifying the correct config file to use (which is actually tirckier than you'd expect.).
The only other hassle I had was an annoying error related to a change introduced in .NET 1.1 to do with typeFilterLevel - this article sorts it all out...