.NET Remoting - Changes for .NET 1.1 / Visual Studio 2003

 

Handling of app.config

Visual Studio .NET 2003 changed the handling of application configuration files. In previous versions, it was ok to have a configuration file named <application>.exe.config directly in the debug\bin output directory. Since Visual Studio 2003, this file will be deleted when you build and/or run the application. To correct this behavior, you have to add the configuration file to your project BEFORE compilation. You can do this by simply dragging and dropping the file from Explorer.

After adding the configuration file to the project, you have to rename it "app.config".

Handling of delegates and events

[Note: You can download an updated version of Chapter 6's EventsEnhanced sample here.]

If you use client activated objects, events or delegates you will receive one of the following exceptions when running on the .NET Framework 1.1:

• System.Security.SecurityException.
  Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.
• System.Runtime.Serialization.SerializationException
  Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed.

To revert to the old behavior (i.e. to allow passing of delegates and object references over Remoting boundaries), you have to change the so called "typeFilterLevel".

You can do this either by using a configuration file like this (for server side):

<configuration>
 <system.runtime.remoting>
  <application>
   <channels>
    <channel ref="http" port="1234">		
     <serverProviders>			
      <provider ref="wsdl" />			
      <formatter ref="soap" typeFilterLevel="Full" />			
      <formatter ref="binary" typeFilterLevel="Full" />
     </serverProviders>
     <clientProviders>
      <formatter ref="binary" />
     </clientProviders>
    </channel>
   </channels>
   <service>
    <!-- ... Add your services here ... -->
   </service>
  </application>
 </system.runtime.remoting>
</configuration>

In this case, a matching client-side configuration file which allows the reception of events and callbacks, would look like this:

<configuration>
 <system.runtime.remoting>
  <application>
   <channels>
    <channel ref="http" port="0">		
     <clientProviders>			
      <formatter ref="binary" />
     </clientProviders>
     <serverProviders>			
      <formatter ref="binary" typeFilterLevel="Full" />
     </serverProviders>			
    </channel>
   </channels>
   <client>
     <!-- ... Add your classes here ... -->
   </client>
  </application>
 </system.runtime.remoting>
</configuration>

If you prefer to setup your channels in source code, you have to use the extended constructor of the HttpChannel or TcpChannel to pass a custom IFormatterSinkProvider object:

BinaryServerFormatterSinkProvider serverProv = new BinaryServerFormatterSinkProvider();
provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;

BinaryClientFormatterSinkProvider clientProv = new BinaryClientFormatterSinkProvider();

IDictionary props = new Hashtable();
props["port"] = 1234;

HttpChannel chan = new HttpChannel(props, clientProv, provider);        
ChannelServices.RegisterChannel( chan );

You can find more details about these changes and the possible type filter levels at http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx#00000153.

Handling of Client-Activated Object with SoapSuds Metadata

When you use SoapSuds.exe to generate the metadata for your client-activated objects, and you run your application on version 1.1 of the .NET Framework, an exception similar to the following will be thrown:

An unhandled exception of type 'System.Runtime.Remoting.RemotingException' occurred in mscorlib.dll 

Additional information: Permission denied for activating type soap:SomeObject, 
http://schemas.microsoft.com/clr/nsassem/Server/Server%2C%20Version%3D1.0.701.21741
%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull. 

This is a bug in the current version of the .NET Framework. Microsoft has released a hotfix which you can obtain from Microsoft Product Support Services. Please read knowledge base article 823445 for more details.

If you don't want to contact Microsoft Product Support Services, then you can alternatively change your source code to use a class factory approach as shown in this article.