Ingo has some new guidance around Remoting. While I don't agree with him on giving any "perfectly okay" marks the WAN case in his feature/scenarios matrix, most of the rules make sense to me for a LAN scenario that doesn't need to scale heavily. Still, the "put state into the database" rule is a bit strict and probably needs a little more thought; after all, the database is just another shared service. Also, in a LAN where security doesn't play much of a role, you probably also don't need to scale unexpectedly as it happens on the web and therefore the whole "host in IIS" and "single call only" business seems a bit strict, too.

And if you didn't believe me until now, here's Ingo with some definitive guidance around ASMX, ES and Remoting that I obviously very much agree with:

• If you plan on using SOAP Web Services to integrate different platforms or different companies, I really urge you to look into ASMX (ASP.NET) Web Services instead of Remoting.
• Do not try to fit distributed transactions, security, and such into custom channel sinks. Instead, use Enterprise Services if applicable in your environment.

I summarize his guidance for an old COM guy like myself as:

Whatever was cool with OLE Automation* is cool with Remoting. If the use-case looks much different, look elsewhere. 

*(no security or scalability to worry about, chatty interaction, stateful objects, events, late binding)