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, under
InBetween
namespace) that both client and server have access to
(i.e. Manager.dll will be placed in the same directory as the
ClientUI
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>
-->
<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.