Advanced .NET Remoting,Second Edition

INGO RAMMER AND MARIO SZPUSZTA

Advanced .NET Remoting, Second Edition

Copyright © 2005 by Ingo Rammer and Mario Szpuszta

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means,electronic or mechanical, including photocopying, recording, or by any information storage or retrievalsystem, without the prior written permission of the copyright owner and the publisher.

ISBN (pbk): 1-59059-417-7

Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1

Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrenceof a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademarkowner, with no intention of infringement of the trademark.

Lead Editor: Ewan BuckinghamTechnical Reviewer: Kent SharkeyEditorial Board: Steve Anglin, Dan Appleman, Ewan Buckingham, Gary Cornell, Tony Davis, Jason Gilmore,

Jonathan Hassell, Chris Mills, Dominic Shakeshaft, Jim SumserProject Manager: Laura E. BrownCopy Manager: Nicole LeClercCopy Editor: Ami KnoxProduction Manager: Kari Brooks-CoponyProduction Editor: Ellie FountainCompositor: Kinetic Publishing Services, LLCProofreader: Elizabeth BerryIndexer: John CollinArtist: Kinetic Publishing Services, LLCCover Designer: Kurt KramesManufacturing Manager: Tom Debolski

Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 233 Spring Street, 6thFloor, New York, NY 10013, and outside the United States by Springer-Verlag GmbH & Co. KG, Tiergartenstr. 17,69112 Heidelberg, Germany.

In the United States: phone 1-800-SPRINGER, fax 201-348-4505, e-mail orders@springer-ny.com, or visithttp://www.springer-ny.com. Outside the United States: fax +49 6221 345229, e-mail orders@springer.de,or visit http://www.springer.de.

For information on translations, please contact Apress directly at 2560 Ninth Street, Suite 219, Berkeley,CA 94710. Phone 510-549-5930, fax 510-549-5939, e-mail info@apress.com, or visit http://www.apress.com.

The information in this book is distributed on an “as is” basis, without warranty. Although every precautionhas been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability toany person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectlyby the information contained in this work.

The source code for this book is available to readers at http://www.apress.com in the Downloads section.

To Katja,Who was courageous enough to marry me

even though she knew I would write another book.—Ingo

To my parents—I am so happy that I have you!And to my best friends Dominik and Edi—I enjoy every single moment with you!

—Mario

Contents at a Glance

About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

PART 1 ■ ■ ■ UnderstandingCHAPTER 1 Introduction to Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

CHAPTER 2 .NET Remoting Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

CHAPTER 3 .NET Remoting in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

CHAPTER 4 Configuration and Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

CHAPTER 5 Securing .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

CHAPTER 6 Creating Remoting Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

CHAPTER 7 In-Depth .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

CHAPTER 8 The Ins and Outs of Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

CHAPTER 9 .NET Remoting Tips and Best Practices . . . . . . . . . . . . . . . . . . . . . . . . 275

CHAPTER 10 Troubleshooting .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

PART 2 ■ ■ ■ ExtendingCHAPTER 11 Inside the Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

CHAPTER 12 Creation of Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

CHAPTER 13 Extending .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

CHAPTER 14 Developing a Transport Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

CHAPTER 15 Context Matters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

v

■CONTENTS AT A GLANCEvi

PART 3 ■ ■ ■ ReferenceAPPENDIX A .NET Remoting Usage Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

APPENDIX B .NET Remoting Extensibility Reference . . . . . . . . . . . . . . . . . . . . . . . . 525

APPENDIX C .NET Remoting Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Contents

About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

About the Technical Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

PART 1 ■ ■ ■ Understanding

■CHAPTER 1 Introduction to Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

What Is Remoting? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Scenarios for .NET Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Centralized Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Physical Separation of Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Accessing Other Platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Evolution of Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

DCE/RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

DCOM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

MTS/COM+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Java EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Web Services/SOAP/XML-RPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

.NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

■CHAPTER 2 .NET Remoting Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Advantages of .NET Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Ease of Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Extensible Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Interface Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Serialization of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Lifetime Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Multiserver/Multiclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13vii

Your First Remoting Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

The First Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Extending the Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

■CHAPTER 3 .NET Remoting in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Types of Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

ByValue Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

MarshalByRefObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Types of Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Synchronous Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Asynchronous Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

One-Way Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Multiserver Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Examining a Sample Multiserver Application . . . . . . . . . . . . . . . . . . . 60

Sharing Assemblies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Shared Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Shared Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Shared Base Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

SoapSuds-Generated Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

■CHAPTER 4 Configuration and Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Watch for the Metadata! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

The Problem with SoapSuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Porting the Sample to Use Configuration Files . . . . . . . . . . . . . . . . . . 82

Standard Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

What About Interfaces? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Using the IPC Channel in .NET Remoting 2.0 . . . . . . . . . . . . . . . . . . 102

Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Console Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Windows Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Deployment Using IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

■CONTENTSviii

■CHAPTER 5 Securing .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Building Secure Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Authentication Protocols in Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

NTLM Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Kerberos: Very Fast Track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Security Package Negotiate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Security Support Provider Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Identities and Principals: A Short Overview. . . . . . . . . . . . . . . . . . . . . . . . . 129

Securing with IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Authentication with IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Encryption and IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Security Outside of IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Using the MSDN Security Samples. . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Implementing Authorization in the Server . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Security with Remoting in .NET 2.0 (Beta) . . . . . . . . . . . . . . . . . . . . . . . . . 151

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

■CHAPTER 6 Creating Remoting Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Creating a Server for Your Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Creating a Console Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Creating Windows Forms Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Creating Back-End–Based Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

ASP.NET-Based Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Remoting Components Hosted in IIS As Clients . . . . . . . . . . . . . . . . 172

Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

■CHAPTER 7 In-Depth .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Managing an Object’s Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Understanding Leases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Working with Sponsors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Using the CallContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Security and the Call Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Remoting Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Events: First Take . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Refactoring the Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Why [OneWay] Events Are a Bad Idea . . . . . . . . . . . . . . . . . . . . . . . . 222

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

■CONTENTS ix

■CHAPTER 8 The Ins and Outs of Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

.NET Framework Versioning Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

A Short Introduction to Strong Naming . . . . . . . . . . . . . . . . . . . . . . . 225

Versioning in .NET Remoting—Fundamentals . . . . . . . . . . . . . . . . . . . . . . 233

Versioning of Server-Activated Objects . . . . . . . . . . . . . . . . . . . . . . . 233

Versioning of Client-Activated Objects . . . . . . . . . . . . . . . . . . . . . . . . 240

Versioning of [Serializable] Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Advanced Versioning Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Versioning with Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Versioning Concepts for Serialized Types . . . . . . . . . . . . . . . . . . . . . 256

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

■CHAPTER 9 .NET Remoting Tips and Best Practices . . . . . . . . . . . . . . . . . . 275

.NET Remoting Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Cross-AppDomain Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Cross-Process on a Single Machine. . . . . . . . . . . . . . . . . . . . . . . . . . 276

Cross-Process on Multiple Machines in a LAN. . . . . . . . . . . . . . . . . 276

Cross-Process via WAN/Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Nonusage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

The Nine Rules of Scalable Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Using Events and Sponsors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

How to Notify Nevertheless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Message Queuing to the Rescue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Other Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

SoapSuds vs. Interfaces in .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . 286

Custom Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Scaling Out Remoting Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Load Balancing Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Taking Nodes Online/Offline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Designing Applications for Static Scalability . . . . . . . . . . . . . . . . . . . 299

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

■CHAPTER 10 Troubleshooting .NET Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Debugging Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Manual Breakpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Configuration File Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Local or Remote?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Checking Types on Your Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

■CONTENTSx

BinaryFormatter Version Incompatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Troubleshooting with a Custom Sink . . . . . . . . . . . . . . . . . . . . . . . . . 310

Changing Security Restrictions with TypeFilterLevel . . . . . . . . . . . . . . . . . 311

Using Custom Exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Multihomed Machines and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

Client-Activated Objects Behind Firewalls. . . . . . . . . . . . . . . . . . . . . 317

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

PART 2 ■ ■ ■ Extending

■CHAPTER 11 Inside the Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Looking at the Five Elements of Remoting . . . . . . . . . . . . . . . . . . . . . . . . . 321

A Bit About Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Understanding the Role of Messages. . . . . . . . . . . . . . . . . . . . . . . . . 326

Examining Message Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Serialization Through Formatters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Moving Messages Through Transport Channels. . . . . . . . . . . . . . . . 330

Client-Side Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

ClientContextTerminatorSink and Dynamic Sinks . . . . . . . . . . . . . . 332

SoapClientFormatterSink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

HttpClientChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Server-Side Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

HttpServerChannel and HttpServerTransportSink . . . . . . . . . . . . . . 335

SDLChannelSink. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

SoapServerFormatterSink and BinaryServerFormatterSink . . . . . . 336

DispatchChannelSink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

CrossContextChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

ServerContextTerminatorSink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

LeaseSink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

ServerObjectTerminatorSink and StackbuilderSink . . . . . . . . . . . . . 337

All About Asynchronous Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Asynchronous IMessageSink Processing . . . . . . . . . . . . . . . . . . . . . 338

Asynchronous IClientChannelSink Processing . . . . . . . . . . . . . . . . . 340

Generating the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Handling the Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Server-Side Asynchronous Processing. . . . . . . . . . . . . . . . . . . . . . . . 347

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

■CONTENTS xi

■CHAPTER 12 Creation of Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Understanding Sink Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Creating Client-Side Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

Creating Server-Side Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Using Dynamic Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

■CHAPTER 13 Extending .NET Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Creating a Compression Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Implementing the Client-Side Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Implementing the Server-Side Sink . . . . . . . . . . . . . . . . . . . . . . . . . . 364

Creating the Sink Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Using the Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Extending the Compression Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Encrypting the Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Essential Symmetric Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Creating the Sinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Creating the Providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Passing Runtime Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Changing the Programming Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Using This Sink. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

Avoiding the BinaryFormatter Version Mismatch . . . . . . . . . . . . . . . . . . . . 409

Using a Custom Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Some Final Words of Caution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

■CHAPTER 14 Developing a Transport Channel . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Protocol Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

The Shortcut Route to SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

. . . And Round-Trip to POP3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Character Encoding Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Creating E-Mail Headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Encapsulating the Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

Checking for New Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Registering a POP3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Connecting to .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Implementing the Client Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Creating the Client’s Sink and Provider . . . . . . . . . . . . . . . . . . . . . . . 449

■CONTENTSxii

Implementing the Server Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Creating the Server’s Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458

Wrapping the Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

Using the SmtpChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

Preparing Your Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

Some Final Words of Caution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

■CHAPTER 15 Context Matters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

Working at the MetaData Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Creating a Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

Checking Parameters in an IMessageSink . . . . . . . . . . . . . . . . . . . . . . . . . 480

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

PART 3 ■ ■ ■ Reference

■APPENDIX A .NET Remoting Usage Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 487

System Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

System.Activator Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

System.MarshalByRefObject Class. . . . . . . . . . . . . . . . . . . . . . . . . . . 488

System.SerializableAttribute Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

System.Delegate Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

System.IAsyncResult Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

System.Runtime.Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Basic Infrastructure Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Configuration Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Exception Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

General Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

System.Runtime.Remoting.Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

General Interfaces and Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

System.Runtime.Remoting.Channels.Http . . . . . . . . . . . . . . . . . . . . . . . . . 504

HttpChannel Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

HttpClientChannel Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

HttpServerChannel Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

System.Runtime.Remoting.Channels.Tcp . . . . . . . . . . . . . . . . . . . . . . . . . . 506

TcpChannel Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

TcpClientChannel Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

TcpServerChannel Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

■CONTENTS xiii

System.Runtime.Remoting.Lifetime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

ILease Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

ISponsor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

ClientSponsor Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

LifetimeServices Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

LeaseState Enumeration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

System.Runtime.Remoting.Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

AsyncResult Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

CallContext Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

LogicalCallContext Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

OneWayAttribute Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

System.Runtime.Remoting.Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

SoapAttribute Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

SoapTypeAttribute Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

SoapFieldAttribute Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

SoapMethodAttribute Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

SoapParameterAttribute Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

SoapOption Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

System.Runtime.Remoting.Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

EnterpriseServicesHelper Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

RemotingClientProxy Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

ITrackingHandler Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

TrackingServices Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

System.Runtime.Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

ISerializable Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

SerializationInfo Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

StreamingContext Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

SerializationException Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

System.Runtime.Serialization.Formatters . . . . . . . . . . . . . . . . . . . . . . . . . . 521

SoapFault Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

SoapMessage Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

TypeFilterLevel Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

■APPENDIX B .NET Remoting Extensibility Reference . . . . . . . . . . . . . . . . . . . 525

System.Runtime.Remoting.Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

IMessage Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

IMessageSink Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

IMethodMessage Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

IMethodCallMessage Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

■CONTENTSxiv

IMethodReturnMessage Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

MethodCall Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

MethodResponse Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

System.Runtime.Remoting.Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

IConstructionCallMessage Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 530

IConstructionReturnMessage Interface . . . . . . . . . . . . . . . . . . . . . . . 530

System.Runtime.Remoting.Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530

RealProxy Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

ProxyAttribute Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

System.Runtime.Remoting.Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

IChannelSinkBase Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

IClientChannelSink Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

IClientChannelSinkProvider Interface . . . . . . . . . . . . . . . . . . . . . . . . . 533

IClientFormatterSink Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

IClientFormatterSinkProvider Interface . . . . . . . . . . . . . . . . . . . . . . . 534

IServerChannelSink Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

IServerChannelSinkProvider Interface . . . . . . . . . . . . . . . . . . . . . . . . 535

ITransportHeaders Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536

IChannel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537

IChannelReceiver Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538

IChannelSender Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

BaseChannelObjectWithProperties Class. . . . . . . . . . . . . . . . . . . . . . 539

BaseChannelWithProperties Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

BaseChannelSinkWithProperties Class . . . . . . . . . . . . . . . . . . . . . . . 540

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

■APPENDIX C .NET Remoting Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

Ingo’s .NET Remoting FAQ Corner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

MSDN and MSDN Magazine Articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

“Improving Remoting Performance” . . . . . . . . . . . . . . . . . . . . . . . . . 541

“.NET Remoting Security” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

“Boundaries: Processes and Application Domains”. . . . . . . . . . . . . 542

“.NET Remoting Architectural Assessment” . . . . . . . . . . . . . . . . . . . 542

“.NET Remoting Overview” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

“Building Secure ASP.NET Applications: Authentication,Authorization, and Secure Communication” . . . . . . . . . . . . . . . . . . . 542

“NET Remoting Authentication and Authorization Sample” . . . . . . 542

“Managed Extensions for C++ and .NET Remoting Tutorial” . . . . 543

“.NET Remoting Use-Cases and Best Practices” and “ASP.NET Web Services or .NET Remoting: How to Choose”. . . . . 543

■CONTENTS xv

“Remoting Examples”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

“Secure Your .NET Remoting Traffic by Writing an Asymmetric Encryption Channel” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

“Create a Custom Marshaling Implementation Using .NET Remoting and COM Interop” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

.NET Remoting Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

.NET Remoting: CORBA Interoperability . . . . . . . . . . . . . . . . . . . . . . . 544

.NET Remoting: Java RMI Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

XML-RPC with .NET Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

Custom .NET Remoting Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

Named Pipes Channel for .NET Remoting . . . . . . . . . . . . . . . . . . . . . 545

TcpEx Channel for .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Jabber Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Remoting Channel Framework Extension . . . . . . . . . . . . . . . . . . . . . 545

“Using MSMQ for Custom Remoting Channel”. . . . . . . . . . . . . . . . . 545

“Using WSE-DIME for Remoting over Internet” . . . . . . . . . . . . . . . . 546

Interesting Technical Articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546

C# Corner: Remoting Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546

“Share the ClipBoard Using .NET Remoting” . . . . . . . . . . . . . . . . . . 546

“Chaining Channels in .NET Remoting”. . . . . . . . . . . . . . . . . . . . . . . 546

“Applying Observer Pattern in .NET Remoting” . . . . . . . . . . . . . . . . 546

“Aspect-Oriented Programming Enables Better Code Encapsulation and Reuse” and “.NET Remoting Spied On” . . . . . . 547

“Persistent Events in Stateless Remoting Server”. . . . . . . . . . . . . . 547

“Intrinsyc’s Ja.NET—Extending the Reach of .NET Remoting” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

“Implementing Object Pooling with .NET Remoting—Part I”. . . . . 547

“.NET Remoting Versus Web Services” . . . . . . . . . . . . . . . . . . . . . . . 547

“.NET Remoting Central” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

“Output Caching for .NET Remoting” . . . . . . . . . . . . . . . . . . . . . . . . . 548

“Abstract Client Formatter Sink”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548

Remoting Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548

Remoting Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548

Remoting Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548

■INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

■CONTENTSxvi

About the Authors

■INGO RAMMER is cofounder of thinktecture, a company supporting software architects anddevelopers with architecture and design of .NET and Web Services applications. He is a regularspeaker about these topics at conferences around the world, author of numerous online andprint articles, and winner of the .NET Developer’s Journal’s Readers’ Choice Award for Best .NETBook of 2003. You can reach him at http://www.thinktecture.com/staff/ingo.

■MARIO SZPUSZTA is working in the Developer and Platform Group of Microsoft Austria. Beforehe started working for Microsoft, Mario was involved in several projects based on COM+ andDCOM with Visual Basic and Visual C++ as well as projects based on Java and J2SE. With Beta 2of the .NET Framework, he started developing Web applications with ASP.NET. Right now, asdeveloper evangelist for Microsoft Austria, he is doing workshops, trainings, and proof-of-conceptprojects together with independent software vendors in Austria based on .NET, Web Services,and Office 2003 technologies.

xvii

About the Technical Reviewer

■KENT SHARKEY is currently the content strategist for ASP.NET and Visual Studio content forMSDN. When not answering e-mail, he occasionally writes, codes, and sleeps. He lives in green,green Redmond with his wife, and two furry “children,” Squirrel and Cica.

xix

Acknowledgments

First and foremost, I want to thank Mario for taking the challenge to write the second editionof this book together with me. Without him, this book could not exist.

I especially want to thank those people whom I’ve met in the previous years and whose insightconstantly influenced the way I think about software. A big “thank you” therefore needs to goto Beat Schwegler, Clemens Vasters, Don Box, and Steve Swartz.

But the biggest “thank you” needs to go to the thousands of software developers and archi-tects who contacted me by e-mail, who chatted with me at various conferences, and who wrotethought-provoking Weblog and newsgroup posts. You are the reason why I wrote this book.

Of course, writing a book would not be possible without the support of many people. Eventhough only Mario’s and my name appear on the cover, this book would not have been possiblewithout my fellows at thinktecture: Christian Weyer, Christian Nagel, and Ralf Westphal; myfriend and the technical reviewer for this book, Kent Sharkey; and the fine editorial staff atApress: Laura Brown, Ami Knox, and Ellie Fountain. Thank you for making this book a reality!

—Ingo Rammer

The first large project I started working on was one of the most interesting projects I have everbeen part of. The enthusiasm and creativity of the two masterminds in this team, HaraldLeitenmüller and Benedikt Redl, have inspired me. These two persons have shown me whatsoftware development in large projects really means, and they have shown me how interestingsoftware architecture is! Without them, I would not have progressed even half as far as I havetoday. Therefore, my biggest thanks go to Harald and Benedikt.

Without Beat Schwegler, I would not have had the chance to get involved in writing thisbook. Thank you, Beat, for this great opportunity and much more for the things I have learnedin the past two years from you. These two years have been a really great time!

Last but not least, I want to thank you, Ingo, for giving me the chance to write this book withyou. It was really great. I learned many things, and right now I recognize that writing conceptsand thoughts down is something that can be really funny and, even more so, interesting.

—Mario Szpuszta

xxi

Introduction

In the time since the first edition of this book has been published, quite a bit has changed in theworld of software development on Microsoft’s platforms. The .NET Framework has becomea tried-and-true development platform, and service orientation gained a larger-than-expectedmomentum. The latter especially presents a very challenging task for the developer using .NETRemoting: the need to avoid possible incompatibilities with future paradigms. If service orien-tation will, in the next few years, gain the success it deserves, it might be important for yourapplication to be developed in a way to easily adopt these new ideas.

In this book, I have therefore followed a slightly different approach from the one I did inthe previous edition. While the first book focused only on covering all the features of the .NETRemoting framework, Mario and I tried to extend this second edition with the best practicesfor using this technology. While it still covers nearly each and every feature of the .NET Remot-ing framework, the largest part of the new chapters of this book—especially Chapters 5, 8, 9,and 10—deals with security, best practices, and the general avoidance of problems.

What Is Covered in This BookThis book covers the means of cross-process and cross-machine interaction of applicationsdeveloped with the .NET Framework. It will provide you with an in-depth understanding ofthe remoting capabilities that are built into the .NET Framework.

.NET Remoting is different from most other means of remote object access because it canbe as easy as writing COM components in Visual Basic 6, yet also gives you the option to extendremoting to include virtually any protocol on any transportation layer you will come across.

Part 1 of the book gives you a thorough introduction to .NET Remoting basics and howyou can use .NET Remoting “out of the box.” This gives you a whole range of possibilities, fromfast binary transfer protocol to a cross-platform SOAP protocol, with the potential to switchbetween both without changing a single line in your code. At the end of this part, you will beable to design and develop remoteable components and know just what you have to do to achieveyour goals. This part also deals with objects’ lifetimes, security, versioning, marshalling, anddeployment.

Part 2 covers the advanced features of .NET Remoting and its extensibility model. At theend of the second part, you will have an in-depth understanding of the inner workings ofremoting and will know how to extend the framework to meet your requirements. You shouldnot be afraid, especially as you go through the sample code in the second part of the book, toeither hit F1 or to insert a breakpoint and examine the Locals window in your custom channelsink to see the exact contents of the objects that get passed as parameters to your methods.

xxiii

What This Book Doesn’t CoverThis book is in no way a rehash of the supplied documentation, but is meant to be used inconjunction with it. You will only find a small percentage of the information that is coveredin the online documentation in this book and vice versa, so it is very important for you to usethe .NET Framework SDK documentation as well.

I chose this approach to writing a book for one simple reason: I assume that, as an advanceddeveloper, you don’t have much time to waste going through a 1,000-page book of which 600pages are a reproduction of the online documentation. Instead, you want to read the informa-tion that has not been covered before. If you think so as well, this book is right for you.

Who This Book Is ForThis book is for the intermediate-to-advanced programmer who wants a hands-on guide to .NETRemoting. Although this book is not an introduction to .NET, the CLR, or any .NET language,you nevertheless will be able to use the knowledge and insight you’ll get from this book withany of these programming languages. All the samples printed in this book are written in VisualBasic .NET, but you can download each and every sample in both C# and Visual Basic .NET.

If you are a “use-it” developer, Part 1 (Chapters 1 through 10) of this book will serve you wellby providing a general introduction to the possibilities of remoting and giving you in-depthinformation on how to use the capabilities that come with .NET Remoting “out of the box.” Thispart also includes guidance on security, best practices, and troubleshooting.

If you are more of an “understand-it-and-extend-it” developer, Part 2 of this book is for you.Chapters 11 through 15 were written for those who want to understand what’s going on behindthe scenes of .NET Remoting and how the framework can be customized using proxies, messages,channel sinks, and providers. It also demonstrates how a complete transport channel is imple-mented from scratch.

At the end of the book, you’ll find a collection of appendixes that provide a reference ofthe namespaces, classes, and interfaces that comprise the .NET Remoting framework.

How This Book Is StructuredAdvanced .NET Remoting is divided into two parts. Part 1 (Chapters 1 through 10) covers every-thing you need to know for developing distributed applications within the .NET Framework.Part 2 (Chapters 11 through 15) gives you a thorough technical insight that will allow you toreally understand what’s happening behind the scenes and how you can tap into customizingthe framework to suit your exact needs. Following is a brief chapter-by-chapter summary ofthe topics covered in this book.

Chapter 1: Introduction to RemotingThis chapter gives you a short introduction to the world of distributed application developmentand the respective technologies. It presents some scenarios in which .NET Remoting can beemployed and includes historical background on the progress and development of variousremoting frameworks during the last ten years.

■INTRODUCTIONxxiv

Chapter 2: .NET Remoting BasicsThis chapter gets you started with your first remoting application. Before going directly into thecode, I present the distinctions between .NET Remoting and other distributed application frame-works. I then introduce you to the basic types of remote objects, which are server-activatedobjects and client-activated objects, and show you how to pass data by value. I also give yousome basic information about lifetime management issues and the generation of metadata,which is needed for the client to know about the interfaces of the server-side objects.

Chapter 3: .NET Remoting in ActionIn this chapter, I demonstrate the key techniques you’ll need to know to use .NET Remoting inyour real-world applications. I show you the differences between Singleton and SingleCall objectsand untangle the mysteries of client-activated objects. I also introduce you to SoapSuds, whichcan be used to generate proxy objects containing only methods’ stubs.

Chapter 4: Configuration and DeploymentThis chapter introduces you to the aspects of configuration and deployment of .NET Remotingapplications. It shows you how to use configuration files to avoid the hard coding of URLs orchannel information for your remote object. You also learn about hosting your server-sidecomponents in Windows Services and IIS.

Chapter 5: Securing .NET RemotingThis chapter shows you how to leverage IIS’s features when it comes to hosting your componentsin a secured environment. In this chapter, you learn how to enable basic HTTP sign-on andthe more secure Windows-integrated authentication scheme, which is based on a challenge/response protocol. You also see how to enable encrypted access by using standard SSL certifi-cates at the server side.

You will also read about ways to use .NET Remoting in a secure way when not relying on IIS.

Chapter 6: Creating Remoting ClientsWhenever I explain a new feature of the .NET Remoting framework, I tend to present it in aneasily digestible console application to avoid having to show you numerous lines of boilerplate.NET code.

Of course, most of your real-world applications will either be Windows Forms or ASP.NETWeb applications or Web Services. In this chapter, you therefore learn how to create remotingclients either as desktop or Web applications.

Chapter 7: In-Depth .NET RemotingAs a developer of distributed applications using .NET Remoting, you have to consider severalfundamental differences from other remoting techniques and, of course, from the developmentof local applications. These differences, including lifetime management, versioning, and thehandling of asynchronous calls and events, are covered in this chapter.

■INTRODUCTION xxv

Chapter 8: The Ins and Outs of VersioningHere you learn how to create .NET Remoting applications that are version resilient in a waythat allows you to support different versions of clients with the same server.

Chapter 9: .NET Remoting Tips and Best PracticesIn this chapter, I introduce you to a number of best practices that I’ve learned in more thanthree years of using .NET Remoting in numerous projects. This chapter will help you to increasescalability, performance, and stability of your distributed applications.

Chapter 10: Troubleshooting .NET RemotingUnfortunately, things can and will go wrong at some point in time. That’s why this chapter givesyou a number of techniques and tools that help you to troubleshoot various issues you mightencounter when using .NET Remoting. But don’t be afraid: most of these can be remedied ina very brief amount of time.

Chapter 11: Inside the Framework.NET provides an unprecedented extensibility for the remoting framework. The layered archi-tecture of the .NET Remoting framework can be customized by either completely replacing theexisting functionality of a given tier or chaining new implementation with the baseline .NETfeatures.

Before working on the framework and its extensibility, I really encourage you to get a thoroughunderstanding of the existing layers and their inner workings in this architecture. This chaptergives you that information.

Chapter 12: Creation of SinksThis chapter covers the instantiation of message and channel sinks and sink chains. It showsyou the foundation on which to build your own sinks—something you need to know beforetackling the implementation of custom sinks.

Chapter 13: Extending .NET RemotingThis chapter builds on the information from Chapters 7 and 8 and shows you how to implementcustom remoting sinks. This includes channel sinks that compress or encrypt the transportedinformation, and message sinks to pass additional runtime information from a client to theserver or to change the .NET Remoting programming model. This chapter concludes with show-ing you how to implement custom remoting proxies that forward method calls to remote objects.

Chapter 14: Developing a Transport ChannelThis chapter builds on the information you gained in Chapters 7, 8, and 9 and presents thedevelopment of a custom .NET Remoting channel that transfers messages via standard Internete-mail by using SMTP and POP3. It shows not only the implementation of this channel, butalso the necessary phase of analyzing the underlying protocol to combine it with the featuresand requirements of .NET Remoting.

■INTRODUCTIONxxvi

■INTRODUCTION xxvii

Chapter 15: Context MattersThis last chapter is about message-based processing in local applications. Here you learn howyou can intercept calls to objects to route them through IMessageSinks. This routing allows youto create and maintain parts of your application’s business logic at the metadata level by usingcustom attributes. You also discover why it might or might not be a good idea to do so.

Appendix A: .NET Remoting Usage ReferenceThis first appendix includes reference information you’ll need when using .NET Remoting inyour application. You’ll learn about all the namespaces involved when creating clients andservers, and configuring and troubleshooting your application.

Appendix B: .NET Remoting Extensibility ReferenceThis second appendix covers the namespaces, classes, and interfaces that allow you to extendthe .NET Remoting framework.

Appendix C: .NET Remoting LinksAt the end of this book are collected a number of links to additional .NET Remoting–specificcontent on the Web. This includes everything from Microsoft-provided additional articles tocustom channels and remoting extensions.

Source Code DownloadYou can find all source code presented in this book at the Apress download page at http://www.apress.com. If you have further suggestions or comments or want to access even moresample code on .NET Remoting, you are invited to visit thinktecture’s .NET Remoting FAQ,which is hosted at http://www.thinktecture.com/Resources/RemotingFAQ.

We hope that you will benefit from the techniques and information we provide in this bookwhen building your distributed applications based on the .NET Framework.

Ingo Rammer and Mario SzpusztaVienna, Austria

P A R T 1■ ■ ■

Understanding

3

C H A P T E R 1

■ ■ ■

1. .NET extends this concept to include the ability to define additional contexts within one running appli-cation. Object accesses crossing these boundaries will pass the .NET Remoting framework as well.

Introduction to Remoting

This chapter gives you a short introduction to the world of distributed application develop-ment and its respective technologies. Here you get a chance to examine some scenarios inwhich .NET Remoting can be employed and learn some historical background on the progressand development of various remoting frameworks during the last ten years.

What Is Remoting?Remoting is the process of programs or components interacting across certain boundaries.These contexts will normally resemble either different processes or machines.1 In the .NETFramework, this technology provides the foundation for distributed applications—it simplyreplaces DCOM.

Remoting implementations generally distinguish between remote objects and mobile objects.The former provide the ability to execute methods on remote servers, passing parameters andreceiving return values. The remote object will always “stay” at the server, and only a referenceto it will be passed around among other machines.

When mobile objects pass a context boundary, they are serialized (marshaled) into a generalrepresentation—either a binary or a human readable format like XML—and then deserializedin the other context involved in the process. Server and client both hold copies of the sameobject. Methods executed on those copies of the object will always be carried out in the localcontext, and no message will travel back to the machine from which the object originated. Infact, after serialization and deserialization, the copied objects are indistinguishable from regu-lar local objects, and there is also no distinction between a server object and a client object.

Scenarios for .NET RemotingAt the beginning of the client/server era, remoting was mostly used for accessing a server’sresources. Every database or file server is an implementation of some technique that allows codeto be executed remotely. Programming these older frameworks was so difficult a task that fewproducts except for these server-side core services implemented remoting.

CHAPTER 1 ■ INTRODUCTION TO REMOTING4

Nowadays the building of distributed applications has gotten a lot easier so that it’s quitefeasible to distribute business applications among various machines to improve performance,scalability, and maintainability.

Centralized Business LogicOne of the key scenarios for implementing remoting is the concentration of business logic onone or more central servers. This considerably simplifies the maintainability and operability oflarge-scale applications. Changes in business logic do not entail your having to roll out an appli-cation to your organization’s 10,000 worldwide users—you just have to update one single server.

When this centralized business logic is shared among different applications, this labor-savingeffect multiplies considerably; instead of patching several applications, you just have to changethe server’s implementation.

Physical Separation of LayersThe security of a company’s vital databases represents a common concern in this time ofWeb-enabled businesses. The general recommendation is against directly connecting fromthe Web server to the database because this setup would allow attackers easy access to criticaldata after they have seized control of the Web server.

Instead of this direct connection, an intermediate application server is introduced. Thisserver is placed in a so-called demilitarized zone (DMZ), located between two firewalls. Firewall #1only allows connections from the Web server to the app server, and Firewall #2 only allows con-nections from the app server to the databases.

Because the application server doesn’t allow the execution of arbitrary SQL statements, yetprovides object-oriented or function-based access to business logic, a security compromise ofthe Web server (which can only talk to the app server) is noncritical to a company’s operations.

Accessing Other PlatformsIn today’s mid- to large-scale enterprises, you will normally encounter a heterogeneous combi-nation of different platforms, frameworks, and programming languages. It is not uncommon tofind that a bunch of tools have been implemented: Active Server Pages (ASP), Java Server Pages(JSP), PHP, or ColdFusion for Web applications, Visual Basic or Java for in-house applications,C++ for server-side batch jobs, scripting languages for customizing CRM systems, and so on.

Integrating these systems can be a daunting task for system architects. Remoting architec-tures like CORBA, SOAP, and .NET Remoting are an absolute necessity in large-scale enterpriseapplication integration. (CORBA and SOAP are introduced and compared later in this chapter.)

Evolution of RemotingThe scenarios presented thus far have only been possible due to the constant evolution ofremoting frameworks. The implementation of large-scale business applications in a distributedmanner has only been practicable after the technical problems have been taken care of by theframeworks. CORBA, COM+, and EJB started this process several years ago, and .NET Remotingsimplifies this process even more.

To underscore how far remoting has evolved from its cumbersome beginnings, the followingsections give you a brief history of the various remoting frameworks.

CHAPTER 1 ■ INTRODUCTION TO REMOTING 5

DCE/RPCDistributed Computing Environment (DCE), designed by the Open Software Foundation (OSF)during the early 1990s, was created to provide a collection of tools and services that wouldallow easier development and administration of distributed applications. The DCE frameworkprovides several base services such as Remote Procedure Calls (DCE/RPC), Security Services,Time Services, and so on.

Implementing DCE is quite a daunting task; the interfaces have to be specified in InterfaceDefinition Language (IDL) and compiled to C headers, client proxies, and server stubs by an IDLcompiler. When implementing the server, one has to link the binary with DCE/Threads, whichare available for C/C++. The use of programming languages other than these is somewhatrestricted due to the dependence on the underlying services, like DCE/Threads, with the resultthat one has to live with single-threaded servers when refraining from using C/C++.

DCE/RPC nevertheless is the foundation for many current higher-level protocols includingDCOM and COM+. Several application-level protocols such as MS SQL Server, Exchange Server,Server Message Block (SMB), which is used for file and printer sharing, and Network File System(NFS) are also based on DCE/RPC.

CORBADesigned by the Object Management Group (OMG), an international consortium of about 800companies, CORBA’s aim is to be the middleware of choice for heterogeneous systems. OMG’sCORBA, which stands for Common Object Request Broker Architecture, is only a collection ofstandards; the implementation of object request brokers (ORBs) is done by various third parties.Because parts of the standard are optional and the vendors of ORBs are allowed to include addi-tional features that are not in the specifications, the world has ended up with some incompatiblerequest brokers. As a result, an application developed to make use of one vendor’s featurescould not easily be ported to another ORB. When you buy a CORBA-based program or compo-nent, you just can’t be sure if it will integrate with your CORBA applications, which probablywere developed for a different request broker.

Aside from this potential problem, CORBA also has quite a steep learning curve. The standardreads like a complete wish list of everything that’s possible with remoted components—sometimesit simply is too much for the “standard business.” You’ll probably end up reading documentsfor days or weeks before your first request is ever sent to a server object.

Nevertheless, when you have managed to implement your first CORBA application, you’llbe able to integrate a lot of programming languages and platforms. There are even layers forCOM or EJB integration, and apart from SOAP, CORBA is the only true multiplatform, multi-programming language environment for distributed applications.

DCOMDistributed Component Object Model (DCOM) is an “extension” that fits in the ComponentObject Model (COM) architecture, which is a binary interoperability standard that allows forcomponent-oriented application development. You’ll usually come in contact with COM whenusing ActiveX controls or ActiveX DLLs.

DCOM allows the distribution of those components among different computers. Scalability,manageability, and its use in WANs pose several issues that need to be addressed. DCOM uses

CHAPTER 1 ■ INTRODUCTION TO REMOTING6

a pinging process to manage the object’s lifetimes; all clients that use a certain object will sendmessages after certain intervals. When a server receives these messages, it knows that the clientis still alive; otherwise it will destroy the object.

Additionally, reliance on the binary DCE/RPC protocol poses the need for direct TCPconnections between the client and its server. Use of HTTP proxies is not possible. DCOM isavailable for Microsoft Windows and for some UNIX dialects (ported by the German companySoftware AG).

MTS/COM+COM+, formerly Microsoft Transaction Server (MTS), was Microsoft’s first serious attempt toreach into the enterprise application domain. It not only serves as a remoting platform, butalso provides transaction, security, scalability, and deployment services. COM+ componentscan even be used via Microsoft Message Queue Server to provide asynchronous execution ofmethods.

Despite its advantages, COM+ does not yet support the automatic marshalling of objects topass them by value between applications; instead you have to pass your data structures usingADO recordsets or other means of serialization. Other disadvantages that keep people fromusing COM+ are the somewhat difficult configuration and deployment, which complicates itsuse for real-world applications.

Java RMITraditional Java Remote Method Invocation (Java RMI) uses a manual proxy/stub compilationcycle. In contrast to DCE/RPC and DCOM, the interfaces are not written in an abstract IDL butin Java. This is possible due to Java being the only language for which the implementation ofRMI is possible.

This limitation locked RMI out of the game of enterprise application integration. Even thoughall relevant platforms support a Java Virtual Machine, integration with legacy applications isnot easily done.

Java EJBEnterprise Java Beans (EJB) was Sun’s answer to Microsoft’s COM+. Unlike CORBA, which is onlya standard, EJB comes with a reference implementation. This allows developers to check if theirproducts run in any standard-complying EJB container. EJB has been widely accepted by theindustry, and there are several container implementations ranging from free open source tocommercial implementations by well-known middleware vendors.

One problem with EJB is that even though a reference implementation exists, most vendorsadd features to their application servers. When a developer writes a component that uses oneof those features, the application will not run on another vendor’s EJB container.

Former versions of EJB have been limited to the Java platform because of their internalreliance on RMI. The current version allows the use of IIOP, which is the same transfer protocolCORBA uses, and third parties already provide commercial COM/EJB bridges.

CHAPTER 1 ■ INTRODUCTION TO REMOTING 7

Web Services/SOAP/XML-RPCWeb Services provided the first easy to understand and implement solution to true cross-platformand cross-language interoperability. Web Services technically are stateless calls to remote compo-nents via HTTP POST with a payload encoded in some XML format.

Two different XML encodings are currently in major use: XML-RPC and SOAP. XML-RPC canbe described as a poor man’s SOAP. It defines a very lightweight protocol with a specification sizeof about five printed pages. Implementations are already available for a lot of programmingenvironments, ranging from AppleScript to C/C++, COM, Java, Perl, PHP, Python, Tcl, andZope—and of course there’s also an implementation for .NET.

SOAP, or Simple Object Access Protocol, defines a much richer set of services; the specificationcovers not only remote procedure calls, but also the Web Services Description Language (WSDL)and Universal Description, Discovery, and Integration (UDDI). WSDL is SOAP’s interface defini-tion language, and UDDI serves as a directory service for the discovery of Web Services. Thoseadditional protocols and specifications are also based on XML, which allows all SOAP featuresto be implemented on a lot of platforms.

The specifications and white papers for SOAP, WSDL, UDDI, and corresponding technolo-gies cover several hundred pages, and you can safely assume that this document will grow fur-ther when topics like routing and transactions are addressed. Fortunately for .NET developers,the .NET platform takes care of all issues regarding SOAP.

.NET RemotingAt first look, .NET Remoting is to Web Services what ASP has been to CGI programming. It takescare of a lot of issues for you: contrary to Web Services, for example, .NET Remoting enables youto work with stateful objects.

In addition to the management of stateful objects, .NET Remoting gives you a flexible andextensible framework that allows for different transfer mechanisms (HTTP and TCP are supportedby default), encodings (SOAP and binary come with the framework), and security settings (IISSecurity and SSL come out of the box).

With these options, and the possibility of extending all of them or providing completely newimplementations, .NET Remoting is well suited to today’s distributed applications. You canchoose between HTTP-based transport for the Internet or a faster TCP-based one for LANapplications by literally changing a single line in a configuration file.

Interface description does not have to be manually coded in any way, even though it’ssupported if you like to design your applications this way. Instead, metadata can be extractedfrom running servers, or from any .NET assembly.

SummaryThis chapter provided a short introduction to the world of distributed application developmentand the respective technologies. You now know about the various scenarios in which .NETRemoting can be applied and understand how it differs from other distributed applicationprotocols and techniques.

9

C H A P T E R 2

■ ■ ■

.NET Remoting Basics

This chapter gets you started with your first remoting application. Before going directly intothe code, I present the differences between .NET Remoting and other distributed applicationframeworks. I then introduce you to the basic types of remote objects, server-activated objects,and client-activated objects, and show you how to pass data by value. I also give you some basicinformation about lifetime management issues and the generation of metadata, which is neededfor the client to know about the interfaces of the server-side objects.

Advantages of .NET RemotingAs you’ve seen in the previous chapter, several different architectures for the development ofdistributed applications already exist. You might therefore wonder why .NET introduces another,quite different way of developing those kinds of applications. One of the major benefits of .NETRemoting is that it’s centralized around well-known and well-defined standards like HTTP andthat it is directly tied to the .NET Framework and has not been retrofitted later.

Ease of ImplementationComparing .NET Remoting to other remoting schemas is like comparing COM development inVisual Basic to C++. Visual Basic 6 allowed developers to concentrate on the business needs theirapplications had to fulfill without having to bother with the technical details of COM. The C++programmers had to know the exact specifications of COM (at least before the introduction ofATL) and implement truckloads of code for supporting them.

With .NET this concept of absolute ease of implementation has been extended to the devel-opment of distributed applications. There are no proxy/stub-compilation cycles as in Java RMI.You don’t have to define your interfaces in a different programming language as you would withCORBA or DCOM. A unique feature is that you don’t have to decide up front on the encodingformat of remoting requests; instead, you can switch from a fast TCP transport to HTTP bychanging one word in a configuration file. You can even provide both communication channelsfor the same objects by adding another line to the configuration. You are not fixed on one plat-form or programming language as with DCOM, COM+, and Java EJB. Configuration and deploy-ment is a lot easier than it was in DCOM.