Introduction

The following article's aim is to help those of you who want to use .NET Remoting on Framework 1.1*. This article will not teach you Remoting, mainly because I am not an expert on that field. Furthermore, my CodeProject colleagues published some useful and nice to read articles on that issue (see links below). The attached projects were kept simple as possible to allow you to overcome the changes presented by Framework 1.1*. It handles the maladies of security exception, serialization and delegates issues.

Background

Recently, I have faced the challenge of exposing objects via .NET Remoting. Like the most of you, I have started with the MSDN, and of course CodeProject, but all the examples were suited for Framework 1.0 only. Attempts to run 1.0 project on a 1.1 Framework ends with lots of exceptions.

Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.

Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed.

This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server.

The web is full of developers' complaints on the very same problems but I have not found a simple, corrective and comprehensive example. So there you have it!.

Code snippets

Activate through Config files

Server side configuration

<system.runtime.remoting><applicationname="ServerAssembly"><service><!-- type: is the full type name
(type the class that inherit from MBR,assembly) of the
object--><!-- objectUri - alias --><!-- Server tells remoting Here's a type
Here's how and when to instantiate the type
Here's the name (end point) a client will use to contact the type
--><wellknownmode="Singleton"type="SharedAssembly.SharedObj, SharedAssembly"objectUri="ParachuteExample"/></service><channels><channelref="tcp"port="6123"><serverProviders><formatterref="binary"typeFilterLevel="Full"/></serverProviders></channel></channels></application></system.runtime.remoting>

Using the code

Since some of you like configuration files while others like to connect and create the well known object via code, I have included two projects accordingly. Both projects, codeActivationExample.zip and configFileExample.zip, include the same assemblies as follows:

ClientAssembly

ServerAssembly

SharedAssembly

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Description: the client proxy couldn’t be able to desterilize your custom Exception (e.g. MYException).
Fix – Use the following rules to define a custom exception that can be desterilize:
Step one
using System.Runtime.Serialization;

Description: General error when defining overloading methods of a certain type in a remote object. The problem occurs only when the proxy is involved, hence not when the client and the server are on the same machine.
For example:
public void method (int var)

Title Ex: “An unhandled exception of type 'System.Runtime.Remoting.RemotingException' Occurred in mscorlib.dll Additional information: .Config file XX.exe.config can not be readsuccessfully due to exception System.IO.FileNotFoundException: The system cannot find the file specified “
Description: The FileNotFoundException indicates that the config file is not in the near the running process.
Fix: Use the following:
string sConfigFilePath = System.Environment.CurrentDirectory + "\\XX.exe.config";
RemotingConfiguration.Configure(sConfigFilePath);

Descriptions: This Is a classic annoying error.
It happens on Frameword 1.0 as well as in 1.1

Fix –
You can turn the CustomErrors to “Off” but it only work on the same machine. Not if the client and server are in different machines
Check to see if we have full errors.
if( RemotingConfiguration.CustomErrorsEnabled( false ) == true )
Make sure the Exception object is a standard .Net Remoting standard Exception:
Step one
using System.Runtime.Serialization;

Step Three
The user define exception class must, implement the ISerializable interface or mark it with the [Serializable] attribute.
http://dotnetjunkies.com/WebLog/chris.taylor/archive/2004/01/10/5441.aspx