Custom Serilalizable Object as WebService Param

[Techno_Dex]

I have a custom object that I have written which is serializable. I have
put this object in it's own dll which is referenced by both the WebService
and the Application using it. My problem is the WebService Proxy creates
it's own implementation of my CustomObject which is causing issues.

Is there some way to mark my object to use it's own namespace instead of
using the namespace of the object being recreated by the WebService Proxy?

I have a Public Static Method which is used to instantiate a new object,
load some default values and return the new object to be loaded with the
data before passing it to the webservice. The problem is the WebService
Proxy version of my custom object does not have the Public Static Method on
it. Is there a way to resolve this (besides making the constructor public)?

[Sebastian Ca?ueto]

Hi pal, as far as i can understand your problem, i see that the point here is that you have a custom class server-side defined, and that class is used and wrapped by 2 different webservices. The other problem is that you can't use the public static constructor client-side.
Well i hope it helps, here is my answer.
First of all, i think you won't be able to use that constructor, because the wrapped classes (objects autogenerated by the WSDL to use as proxies) only have the properties, as member variables, of the server-side custom class and the default constructor i.e. MyClass().
For the other problem the solution is to modify the reference file, because if you use xml namespaces you will continue with the same problem. To explain this let's use an example:
Suppose that you have defined a Serializable MyClass, and two webservices MyService1 and MyService2, and both use MyClass. Then, when you generate the proxies you have MyService1.MyClass and MyService2.MyClass as not compatible or casteable client-side classes. So what you have to do is to edit the reference.cs of one of the webreferences (remember to push the "See all files" button to see this file in the Solution Explorer). Now, in the file, delete de wrapper class MyClass and a "using" directive (using MyClientProject.MyService1;), and the problem is solved, MyClass will be unique for both webservices.

Hope it helps, Bye.
---
Posted via www.DotNetSlackers.com

[Techno_Dex]

The public static functionality makes sense as WSDL is simple by design...
My questions is on a slightly different path though. I'm only working with
a single WebService (at this point). I was mainly looking for some
attribute tag or Interface which can be declared in my Serializable
class/object which would cause both the WebService and the Proxy class
generated by WSDL to use the same namespace of my custom object (similar to
a DataSet or a DataTable). This way my client side app which consumes the
WebService can expect the object as intantiated in the WebService instead of
the one created by the Proxy Class via WSDL. In other words when returning
something of type DataTable from a WebService, the Proxy Class actually
creates a return type of System.Data.DataTable and not
CustomWebService.Proxy.DataTable.

<Sebastian Ca?uetowrote in message
news:eC*************@TK2MSFTNGP02.phx.gbl...

Hi pal, as far as i can understand your problem, i see that the point here
is that you have a custom class server-side defined, and that class is
used and wrapped by 2 different webservices. The other problem is that you
can't use the public static constructor client-side.
Well i hope it helps, here is my answer.
First of all, i think you won't be able to use that constructor, because
the wrapped classes (objects autogenerated by the WSDL to use as proxies)
only have the properties, as member variables, of the server-side custom
class and the default constructor i.e. MyClass().
For the other problem the solution is to modify the reference file,
because if you use xml namespaces you will continue with the same problem.
To explain this let's use an example:
Suppose that you have defined a Serializable MyClass, and two webservices
MyService1 and MyService2, and both use MyClass. Then, when you generate
the proxies you have MyService1.MyClass and MyService2.MyClass as not
compatible or casteable client-side classes. So what you have to do is to
edit the reference.cs of one of the webreferences (remember to push the
"See all files" button to see this file in the Solution Explorer). Now, in
the file, delete de wrapper class MyClass and a "using" directive (using
MyClientProject.MyService1;), and the problem is solved, MyClass will be
unique for both webservices.

Hope it helps, Bye.
---
Posted via www.DotNetSlackers.com