Okay. I should probably disable that on the server then considering I don't think I'll be using it. I'm pretty sure I inadvertently had Com+ enabled when I first installed application server. That's pretty interesting though. It looks like Project Jenks could be getting a rethinking after this series of messages, and not to mention, I haven't even done a WCF demo yet, though I can't wait till I get there.
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Paul Glavich Sent: Monday, February 04, 2013 5:53 PM To: 'ozDotNet' Subject: RE: SPAM-LOW Re: WCF service best practises 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: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com] 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: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com] 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
