Remoting Class From Seperate DLL

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.RealSchem aType.Resolve(StringBuilde
r sb) at System.Runtime.Remoting.MetadataServices.XMLNamesp ace.Resolve() at
System.Runtime.Remoting.MetadataServices.WsdlGener ator.Resolve() at
System.Runtime.Remoting.MetadataServices.WsdlGener ator.Generate() at
System.Runtime.Remoting.MetadataServices.SUDSGener ator.Generate() at
System.Runtime.Remoting.MetadataServices.MetaData. ConvertTypesToSchemaToStre
am(ServiceType[] serviceTypes, SdlType sdlType, Stream outputStream) at
System.Runtime.Remoting.MetadataServices.SdlChanne lSink.GenerateSdl(SdlType
sdlType, IServerResponseChannelSinkStack sinkStack, ITransportHeaders
requestHeaders, ITransportHeaders responseHeaders, Stream& outputStream) at
System.Runtime.Remoting.MetadataServices.SdlChanne lSink.ProcessMessage(IServ
erChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requestStream, IMessage& responseMsg,
ITransportHeaders& responseHeaders, Stream& responseStream) at
System.Runtime.Remoting.Channels.Http.HttpServerTr ansportSink.ServiceRequest
(Object state) at
System.Runtime.Remoting.Channels.SocketHandler.Pro cessRequestNow()

re: Remoting Class From Seperate DLL

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


In article <eW8u0vKPEHA.680@TK2MSFTNGP11.phx.gbl>, richardb@rogge.co.uk
says...[color=blue]
> 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.RealSchem aType.Resolve(StringBuilde
> r sb) at System.Runtime.Remoting.MetadataServices.XMLNamesp ace.Resolve() at
> System.Runtime.Remoting.MetadataServices.WsdlGener ator.Resolve() at
> System.Runtime.Remoting.MetadataServices.WsdlGener ator.Generate() at
> System.Runtime.Remoting.MetadataServices.SUDSGener ator.Generate() at
> System.Runtime.Remoting.MetadataServices.MetaData. ConvertTypesToSchemaToStre
> am(ServiceType[] serviceTypes, SdlType sdlType, Stream outputStream) at
> System.Runtime.Remoting.MetadataServices.SdlChanne lSink.GenerateSdl(SdlType
> sdlType, IServerResponseChannelSinkStack sinkStack, ITransportHeaders
> requestHeaders, ITransportHeaders responseHeaders, Stream& outputStream) at
> System.Runtime.Remoting.MetadataServices.SdlChanne lSink.ProcessMessage(IServ
> erChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
> requestHeaders, Stream requestStream, IMessage& responseMsg,
> ITransportHeaders& responseHeaders, Stream& responseStream) at
> System.Runtime.Remoting.Channels.Http.HttpServerTr ansportSink.ServiceRequest
> (Object state) at
> System.Runtime.Remoting.Channels.SocketHandler.Pro cessRequestNow()
>
>
>[/color]

re: Remoting Class From Seperate DLL

I would recommend switching to an abstract class or interface based
approach. See examples in my article here

http://www.glacialcomponents.com/Art...D=RemoteObject


Allen Anderson
http://www.glacialcomponents.com
mailto: allen@put my website url here.com


On Tue, 18 May 2004 08:44:27 +0100, "Richard Bell"
<richardb@rogge.co.uk> wrote:
[color=blue]
>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.RealSche maType.Resolve(StringBuilde
>r sb) at System.Runtime.Remoting.MetadataServices.XMLNamesp ace.Resolve() at
>System.Runtime.Remoting.MetadataServices.WsdlGene rator.Resolve() at
>System.Runtime.Remoting.MetadataServices.WsdlGene rator.Generate() at
>System.Runtime.Remoting.MetadataServices.SUDSGene rator.Generate() at
>System.Runtime.Remoting.MetadataServices.MetaData .ConvertTypesToSchemaToStre
>am(ServiceType[] serviceTypes, SdlType sdlType, Stream outputStream) at
>System.Runtime.Remoting.MetadataServices.SdlChann elSink.GenerateSdl(SdlType
>sdlType, IServerResponseChannelSinkStack sinkStack, ITransportHeaders
>requestHeaders, ITransportHeaders responseHeaders, Stream& outputStream) at
>System.Runtime.Remoting.MetadataServices.SdlChann elSink.ProcessMessage(IServ
>erChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
>requestHeaders, Stream requestStream, IMessage& responseMsg,
>ITransportHeaders& responseHeaders, Stream& responseStream) at
>System.Runtime.Remoting.Channels.Http.HttpServerT ransportSink.ServiceRequest
>(Object state) at
>System.Runtime.Remoting.Channels.SocketHandler.Pr ocessRequestNow()
>[/color]

re: Remoting Class From Seperate DLL

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.

re: Remoting Class From Seperate DLL

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

In article <#1KzsRbPEHA.1548@TK2MSFTNGP10.phx.gbl>, richardb@rogge.co.uk
says...[color=blue]
> 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.
>
>
>[/color]

re: Remoting Class From Seperate DLL

Why is it less scaleable?

re: Remoting Class From Seperate DLL

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

In article <#8ObC2ePEHA.1312@TK2MSFTNGP12.phx.gbl>, richardb@rogge.co.uk
says...[color=blue]
> Why is it less scaleable?
>
>
>[/color]

re: Remoting Class From Seperate DLL

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.

re: Remoting Class From Seperate DLL

Its more of a deployment issue as opposed to a scalability issue isnt it ;)

Sunny wrote:
[color=blue]
> 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
>
> In article <#8ObC2ePEHA.1312@TK2MSFTNGP12.phx.gbl>, richardb@rogge.co.uk
> says...
>[color=green]
>>Why is it less scaleable?
>>
>>
>>[/color][/color]

--
Regards,
Dilip Krishnan
MCAD, MCSD.net
dilipdotnet at apdiya dot com