Distributed .NET Programming in C#

By: Tom Barnaby

Write A Review

eText | 29 May 2002

At a Glance

Format
PDF

eText

$69.99

or 4 interest-free payments of $17.50 with

Instant online reading in your Booktopia eTextbook Library *

Why choose an eTextbook?

Instant Access *

Purchase and read your book immediately

Read Aloud

Listen and follow along as Bookshelf reads to you

Study Tools

Built-in study tools like highlights and more

* eTextbooks are not downloadable to your eReader or an app and can be accessed via web browsers only. You must be connected to the internet and have no technical issues with your device or browser that could prevent the eTextbook from operating.

COM ON A WIRE, also known as DCOM, was a great boon to the distributed pro grammer. Under the model ofDCOM, a client was able to interact with COM objects located literally anywhere, without requiring a change of code base. Using the indi rection provided by AppiDs, stubs, proxies, and channels, our distributed endeavors involved little more than the use of declarative tools such as dcomcnfg.exe and the Component Services snap-in. However, all was not well in the world ofDCOM (or COM for that matter). Although the clicking of check boxes made COM-based remoting appear quite simple on the surface, we suffered through numerous registry conflicts, a lifetime of passing interface pointers by reference, and the dreaded prospect of crossing firewalls. Just as ADO.NET has nothing to do with classic ADO, the .NET Remoting story has nothing to do with classic DCOM. The most obvious case in point is the fact that .NET assemblies are not registered with the system registry. Given this, we have no AppiD. Without an AppiD, we have no RemoteServerName value, which means no reference to oleaut32.dll and thus no more COM-based stub and proxies. In short, everything we knew about interacting with types across the wire has changed dramatically.