I had the idea that `CreateInstanceAndUnwrap` and `MarshalByRef` used remoting under the covers, any marshalled objects needed to stick to what remoting supports. _Huge_ gotchas in those murky waters...
On Tue, Feb 5, 2013 at 1:31 PM, Paul Glavich <[email protected]>wrote: > 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]> > 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**** > > ** ** >
