.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();
serverProv.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
BinaryClientFormatterSinkProvider clientProv = new BinaryClientFormatterSinkProvider();
IDictionary props = new Hashtable();
props["port"] = 1234;
HttpChannel chan = new HttpChannel(props, clientProv, serverProv);
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.
| 
Architecture Briefings