Delegate Remotable Objects in Simple English (Really, it's that simple)






3.38/5 (8 votes)
Jun 27, 2003
2 min read

68770

1303
Made easy: How to solve the FileNotFoundException error when Remoting.
Introduction
If you recall my last article, which was about a simple remoting chat program (on the .NET Framework SDK v1.0, VB.NET), it had a problem... You could only start the Client.exe from the same directory as the Server.exe. This requirement was because the Client requires some metadata of the Server's assembly to create a proxy version of the Server. Once that is done, only can you start Clients in directories other than the Server. Although the bug was corrected on the .NET Framework SDK, and the solution explained in KB312114 (meant for V1.0), it was rather cryptic. Although they have provided a fix for their console chat program, I would like to present a clearer explanation of what the solution requires and how to do it in C#, on the .NET Framework SDK v1.1.
Cause
In simple English, delegates require that the receiving object (our
ClientUI
) be able to obtain the type information from the Server
assembly.
Solution
The fix requires a design which would look a bit like above.
- STEP 1: Create an abstract class, make sure its accessible from both
ClientUI
and Server.To make remoted delegates work on our remoting chat, an abstract class (in this case,
RemotelyDelegatableObject
) that contains the callback function must be placed in a common assembly (Manager.dll, underInBetween
namespace) that both client and server have access to (i.e. Manager.dll will be placed in the same directory as theClientUI
and Server). - STEP 2: Implement the abstract class
The solution requires that our client (
ClientUI
) derives a custom class (OurCallBack
class) from this abstract class (RemotelyDelegatableObject
) to implement the logic in the callback. - STEP 3: Create a public function (
OurInternalCallback
) for the callback that is final (cannot be overridden)Using the function, forward all calls to a protected abstract function (
private
,abstract
,OurInternalCallback
) that is overridden in the derived client class,ClientUI
. This allows the delegate to bind to a concrete implementation of the callback function (OurInternalCallback
), and this implementation must not be overridable.
Note: SubmitEventArgs
was inherited from EventArgs
just to allow us to pass in more custom information.
Adapting to V1.1
Adapting to V1.1 requires a minor change to our config files.
We need to add the typeFilterLevel
to the Formatter
tag.
Shown below is our .config for ClientUI.exe.
<configuration>
<system.runtime.remoting>
<application>
<client>
<!-- TODO: Change the host and port name -->
<wellknown
type="InBetween.Manager, Manager"
url="http://UP:12345/RemotingChat"
/>
</client>
<channels>
<channel
ref="http"
name="ClientRemotingChatChannel"
port="8888">
<clientProviders>
<formatter ref="soap" />
</clientProviders>
<serverProviders>
<formatter ref="soap" typeFilterLevel="Full" />
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Shown below is our .config for Server.exe.
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
type="InBetween.Manager, Manager"
objectUri="RemotingChat"
mode="Singleton"
/>
</service>
<channels>
<channel
ref="http server"
name="RemotingChatChannel"
port="12345">
<serverProviders>
<provider ref="wsdl" />
<formatter ref="soap" typeFilterLevel="Full" />
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
History
Friday 27, June 2003: Uploaded first version.