You can get away without directly using remoting if you want appDomain isolation. In our app, we have a threadpool and an appDomain pool. Some items get shunted off to threads to do some work, some off to separate appDomains for the isolation you mentioned. You can use the AppDomain object itself, then use the 'CreateInstanceAndUnwrap' method to create an instance of a 'MarshalByRef' object, then execute methods off that.
When all is done, use the AppDomain.Unload method to get rid of it. And no, just going across appDomains, I would not use the mentioned technologies (WebApi etc..) as you would be seriously wasting time with unnecessary network calls, serialisation/de serialisation etc.. - Glav From: [email protected] [mailto:[email protected]] On Behalf Of Ben Scott Sent: Tuesday, 5 February 2013 12:02 PM To: ozDotNet Subject: Re: SPAM-LOW Re: WCF service best practises 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] <mailto:[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]> [mailto:[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]> [mailto:[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
