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 of DCOM (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.