All the different .NET Remoting varieties have similar but not identical configuration files. And there are a lot of optional elements I am not showing. My description here is by no means complete. (For a full description of remoting configuration files, see the MSDN article
What I’m trying to do is clear up some of the simple stuff for myself. So if someone sees an error here, I really would appreciate knowing.
Remote objects can be CAOs or SAOs and when they are SAOs, they can be singleton (stateful and all clients share state) or single-call (stateless). CAOs are stateful , and each client has its own state.
SAO (server side)
On the server, the config file looks like …
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.runtime.remoting>
<application>
<lifetime>
</lifetime>
<service>
<wellknown mode = "Singleton"
type = "StepByStep3_1.DbConnect, StepByStep3_1"
objectUri="DbConnect" />
</service>
<channels>
<channel ref="tcp" port="1234" />
</channels>
</application>
</system.runtime.remoting>
</configuration>
Well, that you have a <service></service> element tells me that this is a config file on a server. <wellknown … /> tells me that it is an SAO; the mode attribute makes it a singleton.
This file chooses a tcp channel, but it could just as easily been an http channel.
Often for examples, I just create a console application as a simple server to host the remotable class. I could instead run the server process as a Win service or use IIS as an activation agent for the server process.
If you wanted to use IIS as an activation agent, the channel would have to be http. Also, the objectUri value would have a .rem extension. My server would be a web app and the configuration would be in web.config. I would not specify a port number because IIS automatically uses port 80. I wouldn’t have a <channels></channels> element either. My web.config would look like …
<wellknown mode="Singleton"
type="StepByStep3_10.DbConnect, StepByStep3_10"
objectUri="DbConnect.rem" />
<!-- other web.config stuff -->
SAO (client side)
On the client side, the config file (for the app that uses the remote object) looks like …
<client>
<wellknown
url="tcp://localhost:1234/DbConnect" />
</client>
That you have a <client></client> element tells me that this is a config file on a client. <wellknown … /> tells me that it is an SAO; there is no mode attribute because the client does not care about the mode.
Note that the value of the url attribute ends with the objectUri of the server-side config file. It also specifies the name of the computer that hosts the remote object and the port it uses. This example uses a tcp channel, but it could just as easily have been an http channel.
However, if you’re using IIS as an activation agent, the channel would have to be http. The url attribute value would end in .rem. And I would not specify a port number.
CAO (server side)
<activated
/>
<channel ref="http" port="1234" />
That you have a <service></service> element tells me that this is a config file on a server. <activated … /> tells me that it is an CAO; there is no mode attribute because the client does not care about the mode.
CAO (client side)
On the client side, the config file looks like …
<client url="http://localhost:1234">
<activated type="StepByStep3_1.DbConnect,StepByStep3_1" />
That you have a <client></client> element tells me that this is a config file on a client. <activated … /> tells me that it is an CAO; there is no mode attribute because the client does not care about the mode.
IIS does not support CAO.
Remember Me
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.
© Copyright 2009, Ted Kubaska
E-mail