soapsuds isn't always the best way to go about accomplishing this. You might consider an interface or abstract class to do this with a bit more ease. Here is an article I wrote on this subject.
On 23 Aug 2005 00:31:43 -0700, "Andrew Shepherd" <shepherd_a@hotmail.com> wrote:
>This is a problem I'm sure that has been countered before. In a
>nutshell, the Soapsuds tool is not generating information about all of
>the public classes in a remote assembly, and I need it to.
>
>The specific example:
>
>I have a remote object and it returns a reference to an abstract base
>class.
>
>eg
>
> public class PnsSystem : MarshalByRefObject
> {
> public PnsSystem()
> {
> }
> public CallResponse CallCrew(string crewName)
> {
> m_fToggle = !m_fToggle;
> if(m_fToggle)
> return new CrewReadyResponse();
> else
> return new CrewNotReadyResponse();
> }
> }
>
>CrewReadyResponse and CrewNotReadyResponse both inherit from
>CallResponse. All three of these classes have the "Serializable"
>attribute. CallResponse is an abstract class.
>
>I expose this object as a WellKnownServiceType in a server component. I
>use the soapsuds tool to generate an Interface Assembly. Using the
>Object Browser, I can see that the Interface Assembly only has the
>PnsSystem and CallResponse class, not the two child classes.
>(CrewReadyResponse and CrewNotReadyResponse). I can also see that
>there's no mention of these when looking at the wsdl via a web browser.
>
>When I invoke the function via remoting, I get an exception of type
>"System.Runtime.Serialization.SerializationException" occuring in
>mscorlib.
>
>Additional information: Parse Error, no assembly associated with Xml
>key
>a1:
http://schemas.microsoft.com/clr/nsassem/TestServerInterface/TestServerInterface%2C%20Version%3D1.0.2061.33048%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull
>CrewNotReadyResponse
>
>
>Being generally optimistic, I'd like to think there's some magic
>attribute I can put somewhere which will make this all work. Am I
>right, or am I being too optimistic here?
