Remoting Class From Seperate DLL

  • Thread starter Thread starter Richard Bell
  • Start date Start date
R

Richard Bell

I have a class in a seperate dll which I want to remote. I have referenced
the class and registered it using a simple exe. I can connect to the class's
interface using Activator.GetObject and call it's methods. However, when I
use soapsuds to extract meta data, I get the following error:

Error: Unable to retrieve schema from url:
http://localhost:1234/RemoteObject.soap?WSDL, The remote server returned an
error: (500) Internal Server Error.

Browser response is below. What am I doing wrong? Thanks.

System.NullReferenceException: Object reference not set to an instance of an
object. at
System.Runtime.Remoting.MetadataServices.RealSchemaType.Resolve(StringBuilde
r sb) at System.Runtime.Remoting.MetadataServices.XMLNamespace.Resolve() at
System.Runtime.Remoting.MetadataServices.WsdlGenerator.Resolve() at
System.Runtime.Remoting.MetadataServices.WsdlGenerator.Generate() at
System.Runtime.Remoting.MetadataServices.SUDSGenerator.Generate() at
System.Runtime.Remoting.MetadataServices.MetaData.ConvertTypesToSchemaToStre
am(ServiceType[] serviceTypes, SdlType sdlType, Stream outputStream) at
System.Runtime.Remoting.MetadataServices.SdlChannelSink.GenerateSdl(SdlType
sdlType, IServerResponseChannelSinkStack sinkStack, ITransportHeaders
requestHeaders, ITransportHeaders responseHeaders, Stream& outputStream) at
System.Runtime.Remoting.MetadataServices.SdlChannelSink.ProcessMessage(IServ
erChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requestStream, IMessage& responseMsg,
ITransportHeaders& responseHeaders, Stream& responseStream) at
System.Runtime.Remoting.Channels.Http.HttpServerTransportSink.ServiceRequest
(Object state) at
System.Runtime.Remoting.Channels.SocketHandler.ProcessRequestNow()
 
Hi, using soapsuds is not good idea. There are a lot of problems with
this. I'd recomend you to use abstract class or interface approach.

Sunny
 
Thanks for your comments, but I want to use the 'new' operator and configure
remoting using the standard framework. The reason it was failing is that my
object exposed an interface which was contained in a separate dll. I have
moved the interface to the server dll and it all works fine. However, I have
2 questions for the group
1) I understood from the Soapsuds docs that classes for the assembly and
referenced assemblies would be imported. This does not appear to be the
case. Can this be forced?
2) Attributes assigned to the objects are not exported in the output
assembly/code. Is it possible to enforce this?
Thanks.
 
Hi Richard,

as a general, I do not recomend to use soapsuds. It's the less scalable
method. Try using abstract classes or interfaces in a separate assembly.

Sunny
 
Lets say, that you find some problem in the server object. You have to
correct this. And now you have a new class. All remoting clients will
fail to use it, unless you recompile them with the new meta data,
extracted from the new class. Even replacing only 50 clients can be a
lot of pain.

And if to search in the newsgroups, you will find a lot of problems
experienced by people, using soapsuds.

Using interfaces, if you do not change the interface assembly, clients
does not have to be touched, they will work with every class which
implements the well known interface.

Or, let's say, you are ready for version 2. You create a new interface,
which extends the previous one. And your server object implements it as
well. Now, the old clients will continue to work using the old
interface, and the new clients, with richer functionality, will use the
new one.

I think that only these 2 reasons are enough.

Sunny
 
OK, thanks, but I do not think that your comments relate to saleability but
to deployment. Even so, I am not sure that I entirely agree with you.

1. You can control how versioning is implemented in the serialization of
calls using the 'includeVersions' and 'strictBinding' attributes of the
formatter element. As long as you do not change the signature of the method
and configure versioning correctly, server rebuilds need not break the
client. The server side execution of Invoke should continue to work. You
only have issues with strongly named assemblies where versioning appears to
be enforced for the binary formatter, but you can get round this, if you
want to (but should you?).
2. Using the 'new' operator does not preclude you from using
interfaces/abstract classes on the client. The issue relates to how the
reference to the remote proxy is obtained. In the 'interface only case', the
location of the 'CoClass' is either hardcoded into the app or obtained by
some custom method. In the case of soapsuds, it is obtained by the framework
method.
3. You are not precluded from implementing a v2 interface type framework
using soapsuds. However, using the 'interface only method' can cause
problems in deployment. You cannot force 'old' clients to use the 'old'
assembly since the 'new' assembly will be listening on the same socket the
'old' client is talking to, and, you might want to (ie back to DLL hell).
The Soapsuds framework does allow you to control versioning precisely. In
fact I believe that it was designed with that intent in mind.

So there are pros and cons. However, it seems to me that soapsuds satisfies
the "location transparency" goal of a remoting framework in that neither the
server nor client objects need to know whether they are being remoted or in
fact whether they are being called by a remote object at all.
 
Back
Top