In the MarkPad Code52 project I was using remoting to implement appdomains for plugins, so that plugins couldn't crash the editor. It didn't work, probably due to my inexperience, but it seemed like remoting is still the status quo for appdomains. I don't see why you would try to do that over something like webapi, NancyFx or even SignalR for cross machine comms.
On Tue, Feb 5, 2013 at 8:53 AM, Paul Glavich <[email protected]>wrote: > Nope. Remoting is a way to marshal objects across a boundary whether that > be appDomain (2 separate appDomains on the same machine) or a network > boundary (machine 1 to machine 2). It looks and operates very much like > DCOM if that helps, in that it appears that you have a reference to the > same object on either end. Security wise it is not so strong but it works > well and security can be implemented via it channel sink mechanism. It goes > way back to .Net 1 and is embedded in the core framework. Back in .Net 1 > days it was either ASMX web services or remoting to get across machines. As > already surmised, it is not promoted as a communications or messaging > strategy since it is proprietary and quite low level from a framework > perspective.**** > > ** ** > > System.Net.EnterpriseServices is kind of a COM+/DCOM wrapper for .Net and > allowed things like easily exposing .Net components via COM+/DCOM (as a > ServicedComponent) through the component services manager (although you > don’t have to do this) for use by .Net and non .Net clients alike > (primarily VB 6, C/C++ etc…). I can’t say I have used this namespace in a > while though so memory is a little rusty. The component services manager > also made it easier to manage transaction scopes for components and monitor > their use, in particular distributed transactions. The component services > manager is actually quite powerful. You had a bunch of attributes in the > namespace which allowed participation in DTC trx negotiation. There is more > which I am sure others can highlight for you.**** > > ** ** > > ** ** > > **- **Glav**** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Katherine Moss > *Sent:* Monday, 4 February 2013 5:11 PM > *To:* ozDotNet > *Subject:* RE: SPAM-LOW Re: WCF service best practises**** > > ** ** > > Now, remind me. Is System.Net.EnterpriseServices the same as > System.NET.Remoting? **** > > ** ** > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Greg Keogh > *Sent:* Sunday, February 03, 2013 5:21 PM > *To:* ozDotNet > *Subject:* Re: SPAM-LOW Re: WCF service best practises**** > > ** ** > > Apparently the .NET remoting documentation has been removed and you have > to hunt around in the archives for it now (I haven't looked myself), so > that's probably a hint about being out-of-date. However, I have a > sentimental feeling for remoting as we have an intensely used client-server > app out there that will have its 10th birthday later this year, so by the > date you can tell it started in Framework 1.0 with Remoting. A newer app > from last year uses WCF and despite the extra work it gives us no > particular advantage and it works just the same. If don't need all the > hyped flexibility and generalisation that WCF give you then it doesn't > contribute much.**** > > **** > > If you just want two .NET app ends to talk over tcp or pipe with minimal > configuration or code bloat then remoting is still viable. I have a tiny > utility project with minimal remoting server and client classes that I > throw into a project if I quickly need two things to communicate. However, > there is little need for it lately as loading stuff into an AppDomain and > talking via a proxy is easier, and guess what ... it uses remoting > internally to talk between AppDomains. So remoting isn't dead, it's just > gone into hiding.**** > > **** > > Greg**** >
