I have a remote object that supports a simple interface. I left out
the details in the code that follows in order to present the problem.
public namespace MyNamespace
{
public interface IDbConnect
{
DataSet ExecuteQuery(string strTable);
}
public class DbConnect: MarshalByRefObject, IDbConnect
{
public DbConnect() : this("MyTable")
{
}
public DbConnect(string strTable)
{
...
}
public DataSet ExecuteQuery(string strSelectText)
{
...
}
}
}
I wrote a simple console application that acts as a server and
activates this remoting object. It uses a configuration file to
configure the server as a server activated object (the mode is
irrelevant).
I wrote a simple windows form application that acts as a client to
this server. It uses a configuration file to configure the client.
When I add a reference to the MyNamespace.DbConnect dynamic link
library to my windows application, it works fine. I can use the class
or the interface, and instantiate the class directly or activate the
object via the Activator.GetObject() method, respectively.
The client and the server work as expected.
So I generate an interface assembly with soapsuds, and replace the
reference to the MyNamespace.DbConnect DLL with the reference to the
soapsuds generated interface assembly in my client application. Then I
modify my code to use the direct class instantiation method to
instantiate the remote object, and nothing happens when I run the
client. I don't get an error or an exception.
It's as if the RemotingConfiguration.Configure() method doesn't work
the same as if I had manually programmed the server and client
applications with the usual statements, as follows.
Server:
HttpServerChannel channel = new HttpServerChannel(1234);
ChannelServices.RegisterChannel(channel);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(MyNamespace.DbConnect),
"DbConnect", "WellKnownObjectMode.Singleton");
Client:
HttpClientChannel channel = new HttpClientChannel();
ChannelServices.RegisterChannel(channel);
dbc = (IDbConnect)Activator.GetObject(typeof(IDbConnect),
@"http://localhost:1234/DbConnect");
So my question is: "Is there a known issue with soapsuds generated
interface assemblies and configuration files?"
Rob - 28 Mar 2004 11:14 GMT
More Info...
I modified the code as follows to test my theory that a problem may
exist with soapsuds generated interface assemblies when used with the
RemotingConfiguration.Configure() method. A code fragment follows:
// Register the remote class as a valid type in the client's
application domain
//RemotingConfiguration.Configure("DbConnectClient.exe.config");
HttpClientChannel channel = new HttpClientChannel();
ChannelServices.RegisterChannel(channel);
RemotingConfiguration.RegisterWellKnownClientType(typeof(DbConnect),
"http://localhost:1234/DbConnect");
// Instantiate the remote class
dbc = new DbConnect();
//dbc = (IDbConnect)Activator.GetObject(typeof(IDbConnect),
@"http://localhost:1234/DbConnect");
This works, but it defeats the purposed of using configuration files.
Allen Anderson - 29 Mar 2004 17:54 GMT
soapsuds can be problematic for many reasons, take a look at this
article I wrote on ways to avoid soapsuds altogether.
http://www.glacialcomponents.com/ArticleDetail.aspx?articleID=RemoteObject
Allen Anderson
http://www.glacialcomponents.com
mailto: allen@put my website url here.com
>I have a remote object that supports a simple interface. I left out
>the details in the code that follows in order to present the problem.
[quoted text clipped - 61 lines]
>So my question is: "Is there a known issue with soapsuds generated
>interface assemblies and configuration files?"