The .NET Remoting Namespaces

intrinsic remoting agents.

This comprehensive text starts with a brief overview of the

C# language and then quickly moves to key technical and architectural issues for .NET developers.

Table of Contents

C# and the .NET Platform, Second Edition

Introduction

Part One - Introducing C# and the .NET Platform

Chapter 1 - The Philosophy of .NET

Chapter 2 - Building C# Applications

Part Two - The C# Programming Language

Chapter 3 - C# Language Fundamentals

Chapter 4 - Object-Oriented Programming with C#

Chapter 5 - Exceptions and Object Lifetime

Chapter 6 - Interfaces and Collections

Chapter 7 - Callback Interfaces, Delegates, and Events

Chapter 8 - Advanced C# Type Construction Techniques

Part Three - Programming with .NET Assemblies

Chapter 9 - Understanding .NET Assemblies

Chapter 10 - Processes, AppDomains, Contexts, and Threads

Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming

Part Four - Leveraging the .NET Libraries

Chapter 12 - Object Serialization and the .NET Remoting Layer

Chapter 13 - Building a Better Window (Introducing Windows Forms)

Chapter 14 - A Better Painting Framework (GDI+)

Chapter 15 - Programming with Windows Forms Controls

Chapter 16 - The System.IO Namespace

Chapter 17 - Data Access with ADO.NET

Part Five - Web Applications and XML Web Services

Chapter 18 - ASP.NET Web Pages and Web Controls

Chapter 19 - ASP.NET Web Applications

Chapter 20 - XML Web Services

Index

List of Figures

List of Tables

When clients and servers exchange information across application boundaries, the CLR makes use of

Apress © 2003 (1200 pages)

several low-level primitives to ensure the entities in question are able to communicate with each other as

This comprehensive text starts with a brief overview of the

transparently as possibleC# language. Meaning,d thenasquicklya .NETmovesprogrammer,to key technicalyou are andnot required to provide reams and reams of grungy architecturalnetworking codeissuestoforinvoke.NETadevmethodloperson. a remote object. Likewise, the server process is not required to manually pluck a network packet out of the queue and reformat the message into terms the remote object can understand. As you would hope, the CLR will take care of such details automatically

Table of Contents

using a default set of remoting types (although you are certainly able to get involved with the process if you

C# and the .NET Platform, Second Edition

so choose).

Introduction

Now, if you are coming to .NET Remoting from a classic DCOM background, do understand that the .NET

Part One - Introducing C# and the .NET Platform

Remoting layer is not quite as transparent as DCOM. Much of the reason has to do with the simple fact

Chapter 1 - The Philosophy of .NET

that .NET assemblies are not registered in the system registry, and therefore you lose any concept of an

Chapter 2 - Building C# Applications

AppID value, which makes the use of dcomcnfg.exe obsolete in the .NET universe.

Part Two - The C# Programming Language

Chapter 3 - C# Language Fundamentals

Although .NET does expose a wee-bit more network-centric details to the developer, the upside is that

Chapter 4 - Object-Oriented Programming with C#

there is no need to manually author IDL code to describe your remotable types (given the advent of .NET

Chapter 5 - Exceptions and Object Lifetime

metadata), and you can forget all about implementing IMarshal, IPropertyBag, or making use of ADO

Chapter 6 - Interfaces and Collections

Recordsets to marshal objects by value. Under .NET, marshaling a type by value (e.g., placing a copy of

Chapter 7 - Callback Interfcaller'ss, Delegates, and Events

the remote type into the app domain) is as simple as applying the [Serializable] attribute.

Chapter 8 - Advanced C# Type Construction Techniques

Basically, the .NET Remoting layer revolves around a careful orchestration that takes place between four

Part Three - Programming with .NET Assemblies

key players:

Chapter 9 - Understanding .NET Assemblies

Chapter 10 - Processes, AppDomains, Contexts, and Threads

Proxies

Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming

Part FourMessages- Leveraging the .NET Libraries

Chapter 12 - Object Serialization and the .NET Remoting Layer

Channels

Chapter 13 - Building a Better Window (Introducing Windows Forms)

Chapter 14 - A Better Painting Framework (GDI+)

Formatters

Chapter 15 - Programming with Windows Forms Controls

ChapterLet's check16 - outTheeachSystementity.IO Namespin turn, andce see how their combined functionality facilitates remote method

Chapterinvocations17 -.Data Access with ADO.NET

Part Five - Web Applications and XML Web Services

Chapter 18 - ASP.NET Web Pages and Web Controls

Understanding Proxies and Messages

Chapter 19 - ASP.NET Web Applications

ChapterClients20and- serverXML WebobjectsServicesdo not communicate via a direct connection, but rather through the use of a

Indexmiddleman termed a proxy. Like Java RMI, CORBA and DCOM, the role of a .NET proxy is to fool the

Listclientof Figuresinto believing it is communicating with a local object in the same application domain. To facilitate this Listillusion,of Tablesa proxy has the identical interface (i.e., members, properties, fields, and whatnot) as the remote type it represents. As far as the client is concerned, a given proxy is the remote object, and can be operated on as if it were a true-blue local entity. Under the hood however, the proxy is forwarding calls to the remote type.

Formally speaking, the proxy invoked directly by the client is termed the transparentproxy. This CLR autogenerated entity is in charge of ensuring that the client has provided the correct number of (and type of) parameters to invoke the remote method. Given this, you can regard the transparent proxy as a fixed interception layer that cannot be modified or extended programmatically.

Assuming the transparent proxy is able to verify the incoming arguments, this information is packaged up into another CLR generated type termed the message object. By definition, all message objects implement the System.Runtime.Remoting.Messaging.IMessage interface:

public interface IMessage

{

IDictionary Properties { get; }

As you can see, theThisIMessagecompreheinterfacesive textdefinesstarts witha singlea briefpropertyoverview(namedof the Properties) that provides access to a collection usedC#tolanguagehold theandclientthen-suppliedquickly movesargumentsto key. Oncetechnicalthis andmessage object has been populated

architectural issues for .NET developers.

by the CLR, it is then passed into a closely related type termed the real proxy.

The real proxy is the entity that literally passes the message object into the channel (described

Table of Contents

momentarily). Unlike the transparent proxy, the real proxy can be extended by the programmer, and is C#representedand the .NETbyPlatform,a base classSecondtypeEditionnamed (of course) RealProxy. Again, it is worth pointing out that the CLR

Introductionwill always generate a default implementation of the client-side real proxy, which will serve your needs

PartmostOne(if -notIntroducingall) of theC#timeand. Nevertheless,.NET Platftormgain some insight into the functionality provided by the

Chapabstracter 1 RealProxy- The Philosophybase class,of .NETponder the formal definition type:

Chapter 2 - Building C# Applications

Part Two - The C# Programming Language

public abstract class RealProxy : object

Chapter 3 - C# Language Fundamentals

{

Chapterpublic4 - Objectvirtual-OrientedObjRefProgrammingCreateObjRef(Typewith C# requestedType);

Chapterpublic5 - ExceptionsvirtualandboolObjectEquals(objectLifetime obj);

Chapterpublic6 - Interfacesvirtualnd IntPtrCollec ionsGetCOMIUnknown(bool fIsMarshalled);

public virtual int GetHashCode();

Chapter 7 - Callback Interfaces, Delegates, and Events

public virtual void GetObjectData(SerializationInfo info,

Chapter 8 - Advanced C# Type Construction Techniques

StreamingContext context);

Part Three - Programming with .NET Assemblies

public Type GetProxiedType();

Chapter 9 - Understanding .NET Assemblies

public static object GetStubData(RealProxy rp);

Chapter 10 - Processes, AppDomains, Contexts, and Threads

public virtual object GetTransparentProxy();

Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming

public Type GetType();

Part Four - Leveraging the .NET Libraries

public IConstructionReturnMessage InitializeServerObject(

Chapter 12 - Object Serialization and the .NET Remoting Layer

IConstructionCallMessage ctorMsg);

Chapter 13 - Building a Better Window (Introducing Windows Forms) public virtual IMessage Invoke(IMessage msg);

Chapter 14 - A Better Painting Framework (GDI+)

public virtual void SetCOMIUnknown(IntPtr i);

Chapter 15 - Programming with Windows Forms Controls

public static void SetStubData(RealProxy rp, object stubData);

Chapter 16 - The System.IO Namespace

public virtual IntPtr SupportsInterface(ref Guid iid);

Chapter 17 - Data Access with ADO.NET

public virtual string ToString();

Part Five - Web Applications and XML Web Services

}

Chapter 18 - ASP.NET Web Pages and Web Controls

Chapter 19 - ASP.NET Web Applications

Again, unless you are interested in building a custom implementation of the client-side real proxy, the only

Chapter 20 - XML Web Services

member of interest is RealProxy.Invoke(). Under the hood, the CLR-generated transparent proxy passes

Index

the formatted message object into the RealProxy type via its Invoke() method.

List of Figures

List of Tables

Understanding Channels

Once the proxies have validated and formatted the client-supplied arguments into a message object, this IMessage-compatible type is passed from the real proxy into a channel object. As in other remoting architectures, channels are the entities in charge of transporting a message to the remote object, and if necessary, ensuring that any method return values are passed from the remote object back to the client. Unlike classic DCOM however, .NET channels are not limited to the ORPC (Object Remote Procedure Call) wire protocol. In fact, the .NET base class libraries provide two channel implementations out of the box:

The TCP channel

The HTTP channel

The TCP channel is represented by the TcpChannel class type, and is used to pass messages using the TCP/IP network protocol. TcpChannel is helpful in that the formatted packets are quite lightweight, given

that the messages are converted into a tight binary format using a related binary formatter. The result is

C# and the .NET Platform, Second Edition

that use of the TcpChannel type tends to result in faster remote access. On the downside, TCP channels

by Andrew Troelsen ISBN:1590590554

are not firewall friendly, and may require the services of a system administrator to allow messages to pass

Apress © 2003 (1200 pages)

across machine boundaries (which does indeed echo the same limitations of classic DCOM).

This comprehensive text starts with a brief overview of the

In contrast, the HTTPC# languagechannelandis representedthen quickly bymovesthe HttpChannelto key technicalclassandtype, which converts message

architectural issues for .NET developers.

objects into a SOAP format using a related soap formatter. As you have seen, SOAP is XML-based and thus tends to result in beefier payloads than those used by the TcpChannel type. Given this, using the

HttpChannel can result in slightly slower remote access. On the plus side, HTTP is far more firewall

Table of Contents

friendly, given that most firewalls allow textual packets to be passed over port 80.

C# and the .NET Platform, Second Edition

IntroductionRegardless of which channel type you chose to use, understand that both the HttpChannel and

PartTcpChannelOne - Introductype implementng C# and tthe.IChannel,NET PlatformIChannelSender, and IChannelReciever interfaces (and yes, if

Chapteryou were1 to- ThebuildPhilosophyyour ownofcustom.NET channel type, you make use of these same interfaces). The IChannel Chapterinterface2 (as- Buildingyou willC#seeApplicationsin just bit) defines a small set of members that provide common functionality to PallrtchannelTwo - ThetypesC# .ProgrammingThe role of IChannelSenderLanguage is to define a common set of members for channels that

are able to send information to a specific receiver. On the other hand, IChannelReceiver defines a set of

Chapter 3 - C# Language Fundamentals

members that allow a channel to receive information from a given sender. The HttpChannel and

Chapter 4 - Object-Oriented Programming with C#

TcpChannel types (as you would hope) are able to send and receive network packets, and therefore

Chapter 5 - Exceptions and Object Lifetime

implement all three channel-centric interfaces.

Chapter 6 - Interfaces and Collections

Chapter 7 - Callback Interfaces, Delegates, and Events

To allow the client and server applications to register their channel of choice, you will make use of the

Chapter 8 - Advanced C# Type Construction Techniques

ChannelServices.RegisterChannel() method, which (surprise, surprise) takes a type implementing

Part Three - Programming with .NET Assemblies

IChannel. To preview things to come, the following code snippet illustrates how a server-side application

Chapter 9 - Understanding .NET Assemblies

domain can register an HTTP channel on port 32469 (you see the client's role in just a bit):

Chapter 10 - Processes, AppDomains, Contexts, and Threads

Chapter 11 - Type Reflection, Late Binding, and Attribute-Based Programming

// Create and register a server side HttpChannel on port 32469.

Part Four - Leveraging the .NET Libraries

HttpChannel c = new HttpChannel(32469);

Chapter 12 - Object Serialization and the .NET Remoting Layer

ChannelServices.RegisterChannel(c);

Chapter 13 - Building a Better Window (Introducing Windows Forms)

Chapter 14 - A Better Painting Framework (GDI+)

Chapter 15 - Programming with Windows Forms Controls

Chapter 16 - The System.IO Namespace

Revisiting the Role of .NET Formatters

Chapter 17 - Data Access with ADO.NET

Part Five - Web Applications and XML Web Services

The final piece of the .NET Remoting puzzle is the role of formatter objects. A given channel object

Chapter 18 - ASP.NET Web Pages and Web Controls

(TcpChannel or HttpChannel) leverages a specific internal formatter, whose job it is to translate the

Chapter 19 - ASP.NET Web Applications

message object into protocol specific terms. As you would guess, the TcpChannel type makes use of the

ChapSystemr 20.Runtime- XML Web.SerializationServices .Formatters.Binary.BinaryFormatter type, while the HttpChannel type uses

Indthexfunctionality provided by the System.Runtime.Serialization.Formatters.Soap.SoapFormatter type.

ListGivenof Figuresyour work at the beginning of this chapter, you should already have some insights as to how a given Listchannelof Tableswill format the incoming messages.

Once the formatted message has been generated, it is passed into the channel, where it will eventually reach its destination application domain, at which time the message is formatted from protocol-specific terms back to .NET-specific terms at which point an entity termed the dispatcher invokes the correct method on the remote object.