By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,500 Members | 1,571 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,500 IT Pros & Developers. It's quick & easy.

web service returned object type problem

P: n/a
Hi all.

I have a webservice and a windows app.
both of them reference the same class library called WebServiceTest.Core
that defines a class called Class1.

the webservice exposes a method that looks like this:

[WebMethod]
public WebServiceTest.Core.Class1 GetClass1()
{
return new WebServiceTest.Core.Class1();
}

the windows app has a web reference to the webservice (and a reference to
the class library).
I want (and even expected) the web-method to return a
WebServiceTest.Core.Class1 object but instead it returns a
WebServicesTest.Client.localhost.Class1 where:
WrbServicesTest.Client is the windows app namespace
localhost is the name of the webreference to the web service
Class1 is some generated class that represents the return type.

my question is simple:

I need the original object. this is why both webservice and windows app
reference the shared assembly...
what can I do?
what am I doing wrong?

thanx,

Picho
Nov 23 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Web services is always about XML and interoperability, and the way
WSDL.exe 1.1 works is always to created the object from XML schema that
comes with WSDL file(the types). even if you have to web services that
use a same object, but WSDL.exe 2.0 offers /shared schema across the
service.

for now, assuming that you are writing this against 1.1. you'll have to
manually replace all the instance and definition of
"WebServicesTest.Client.localhost.Class1" in the web reference with your
WebServiceTest.Core.Class1 .
The other way is to use remoting instead of web services, a it is a
better option i both the client and server side are .Net.

Regards
Erymuzuan Mustapa

Picho wrote:
Hi all.

I have a webservice and a windows app.
both of them reference the same class library called WebServiceTest.Core
that defines a class called Class1.

the webservice exposes a method that looks like this:

[WebMethod]
public WebServiceTest.Core.Class1 GetClass1()
{
return new WebServiceTest.Core.Class1();
}

the windows app has a web reference to the webservice (and a reference to
the class library).
I want (and even expected) the web-method to return a
WebServiceTest.Core.Class1 object but instead it returns a
WebServicesTest.Client.localhost.Class1 where:
WrbServicesTest.Client is the windows app namespace
localhost is the name of the webreference to the web service
Class1 is some generated class that represents the return type.

my question is simple:

I need the original object. this is why both webservice and windows app
reference the shared assembly...
what can I do?
what am I doing wrong?

thanx,

Picho

Nov 23 '05 #2

P: n/a

The same question just came up in
microsoft.public.dotnet.framework.webservices. As erymuzuan pointed out
..NET 2.0 will fix the issue once and for all, for now your best choice
is to edit the generated files, or even better, write a simple app or a
perl script that strips out all redundant classes generated from the
WSDL. There's an MSDN article that describes the edits you need [0].

The use of remoting is strongly discouraged [1] at this point with
respect to future interoperability issues and a programming model that
tempts developers to develop strongly coupled systems based on the
distributed object metaphor. Personally, I like the .NET Remoting
framework, and I am somewhat disappointed to see such a fine framework
go away, but knowing the issues ahead I can no longer recommend building
new distributed systems on .NET Remoting. At this point .NET Remoting
should strictly be used for intra-process/cross app domain scenarios.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

[0]
http://msdn.microsoft.com/library/en...vice07162002.a
sp

[1] http://weblogs.asp.net/cschittko/arc...27/143388.aspx
-----Original Message-----
From: Picho [mailto:SP********@telhai.ac.il]
Posted At: Sunday, January 02, 2005 12:31 PM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: web service returned object type problem
Subject: web service returned object type problem

Hi all.

I have a webservice and a windows app.
both of them reference the same class library called WebServiceTest.Core that defines a class called Class1.

the webservice exposes a method that looks like this:

[WebMethod]
public WebServiceTest.Core.Class1 GetClass1()
{
return new WebServiceTest.Core.Class1();
}

the windows app has a web reference to the webservice (and a reference to the class library).
I want (and even expected) the web-method to return a
WebServiceTest.Core.Class1 object but instead it returns a
WebServicesTest.Client.localhost.Class1 where:
WrbServicesTest.Client is the windows app namespace
localhost is the name of the webreference to the web service
Class1 is some generated class that represents the return type.

my question is simple:

I need the original object. this is why both webservice and windows app reference the shared assembly...
what can I do?
what am I doing wrong?

thanx,

Picho

Nov 23 '05 #3

P: n/a
I completely agree with you when you said things between .Net Remoting
framework and web services, I for once without doubt. 9 out 10 will go for
Web Services. Interoperability and future reuse and security(though this
will change in .Net 2.0). But there are times when Remoting is simply the
only sensible choice. For example the sharing for common types and
interfaces, or when performance is a major consideration.. And this goes
without saying , the system will be very tightly coupled, then again that
what remoting is for.

Regards

Erymuzuan Mustapa

"Christoph Schittko [MVP]" <IN**********@austin.rr.com> wrote in message
news:<#b**************@TK2MSFTNGP12.phx.gbl>...
The same question just came up in microsoft.public.dotnet.framework.webservices. As erymuzuan pointed out .NET 2.0 will fix the issue once and for all, for now your best choice is to edit the generated files, or even better, write a simple app or a perl script that strips out all redundant classes generated from the WSDL. There's an MSDN article that describes the edits you need [0]. The use of remoting is strongly discouraged [1] at this point with respect to future interoperability issues and a programming model that tempts developers to develop strongly coupled systems based on the distributed object metaphor. Personally, I like the .NET Remoting framework, and I am somewhat disappointed to see such a fine framework go away, but knowing the issues ahead I can no longer recommend building new distributed systems on .NET Remoting. At this point .NET Remoting should strictly be used for intra-process/cross app domain scenarios. HTH, Christoph Schittko MVP XML http://weblogs.asp.net/cschittko [0] http://msdn.microsoft.com/library/en...vice07162002.a sp [1] http://weblogs.asp.net/cschittko/arc...27/143388.aspx
-----Original Message----- From: Picho [mailto:SP********@telhai.ac.il] Posted At: Sunday, January 02, 2005 12:31 PM Posted To: microsoft.public.dotnet.framework.webservices Conversation: web service returned object type problem Subject: web service returned object type problem Hi all. I have a webservice and a windows app. both of them reference the same class library called WebServiceTest.Core that defines a class called Class1. the webservice exposes a method that looks like this: [WebMethod] public WebServiceTest.Core.Class1 GetClass1() { return new WebServiceTest.Core.Class1(); } the windows app has a web reference to the webservice (and a reference to the class library). I want (and even expected) the web-method to return a WebServiceTest.Core.Class1 object but instead it returns a WebServicesTest.Client.localhost.Class1 where: WrbServicesTest.Client is the windows app namespace localhost is the name of the webreference to the web service Class1 is some generated class that represents the return type. my question is simple: I need the original object. this is why both webservice and windows app reference the shared assembly... what can I do? what am I doing wrong? thanx, Picho


Nov 23 '05 #4

P: n/a
Hello Picho,
The 4 tenets of service orientation i.e. Web services, are

* Boundaries are explicit
* Services are autonomous
* Share schema/contract - not class
* Use policy-based assertions

The third tenet is what yr violating by sharing types. Ultimately, web services
are about passing messages, which means these objects get serialized into
xml messages and deserialized on the other side, so as long as you can have
an object on the otherside with the same values that you sent in you should
be in good shape. The actual types and their namespaces dont really matter.
If you must have the same object you can by all means only you may need to
work out some roundabout tweaks. As Christoph suggests, the next version
of wsdl.exe supports sharing types.

HTH
Regards,
Dilip Krishnan
MCAD, MCSD.net
dkrishnan at geniant dot com
http://www.geniant.com
Hi all.

I have a webservice and a windows app.
both of them reference the same class library called
WebServiceTest.Core
that defines a class called Class1.
the webservice exposes a method that looks like this:

[WebMethod]
public WebServiceTest.Core.Class1 GetClass1()
{
return new WebServiceTest.Core.Class1();
}
the windows app has a web reference to the webservice (and a reference
to
the class library).
I want (and even expected) the web-method to return a
WebServiceTest.Core.Class1 object but instead it returns a
WebServicesTest.Client.localhost.Class1 where:
WrbServicesTest.Client is the windows app namespace
localhost is the name of the webreference to the web service
Class1 is some generated class that represents the return type.
my question is simple:

I need the original object. this is why both webservice and windows
app
reference the shared assembly...
what can I do?
what am I doing wrong?
thanx,

Picho

Nov 23 '05 #5

P: n/a
Thanx guys, this realy helped.

"Christoph Schittko [MVP]" <IN**********@austin.rr.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

The same question just came up in
microsoft.public.dotnet.framework.webservices. As erymuzuan pointed out
.NET 2.0 will fix the issue once and for all, for now your best choice
is to edit the generated files, or even better, write a simple app or a
perl script that strips out all redundant classes generated from the
WSDL. There's an MSDN article that describes the edits you need [0].

The use of remoting is strongly discouraged [1] at this point with
respect to future interoperability issues and a programming model that
tempts developers to develop strongly coupled systems based on the
distributed object metaphor. Personally, I like the .NET Remoting
framework, and I am somewhat disappointed to see such a fine framework
go away, but knowing the issues ahead I can no longer recommend building
new distributed systems on .NET Remoting. At this point .NET Remoting
should strictly be used for intra-process/cross app domain scenarios.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

[0]
http://msdn.microsoft.com/library/en...vice07162002.a
sp

[1] http://weblogs.asp.net/cschittko/arc...27/143388.aspx
-----Original Message-----
From: Picho [mailto:SP********@telhai.ac.il]
Posted At: Sunday, January 02, 2005 12:31 PM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: web service returned object type problem
Subject: web service returned object type problem

Hi all.

I have a webservice and a windows app.
both of them reference the same class library called

WebServiceTest.Core
that defines a class called Class1.

the webservice exposes a method that looks like this:

[WebMethod]
public WebServiceTest.Core.Class1 GetClass1()
{
return new WebServiceTest.Core.Class1();
}

the windows app has a web reference to the webservice (and a reference

to
the class library).
I want (and even expected) the web-method to return a
WebServiceTest.Core.Class1 object but instead it returns a
WebServicesTest.Client.localhost.Class1 where:
WrbServicesTest.Client is the windows app namespace
localhost is the name of the webreference to the web service
Class1 is some generated class that represents the return type.

my question is simple:

I need the original object. this is why both webservice and windows

app
reference the shared assembly...
what can I do?
what am I doing wrong?

thanx,

Picho


Nov 23 '05 #6

P: n/a
Thanx for the reply Christoph.

I am a bit confused.

when this problem first araised for me while writing a server-client
application, I found a detoured solution. since the data transfer needed to
be secured, I binary serialized the returned object, symmetricly encrypted
it, and so the data transported was allways a byte[].

I can still do this - serializing the object and deserializing it on the
client app back to the shared assembly class.

is this ok?

what should I do?
when is .net 2.0 supposed to be out?

I do not perdict x-platform data transport for my server-client application,
but I would still like to see something smooth and readable (that is - no
serialization...).
please note that I go to all this trouble because my objects are not so
simple and need all the capabilities for oo design (polymorphism,
inheritance, interface implementation, events etc) and therefor creating
adapters from the generated schemes to the original classes are out of the
question.

so what do you say?
what should I do NOW in order to be ready for the FUTURE?
use remoting?
serialize and transfer byte[]?
twick the generated files?
"Christoph Schittko [MVP]" <IN**********@austin.rr.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

The same question just came up in
microsoft.public.dotnet.framework.webservices. As erymuzuan pointed out
.NET 2.0 will fix the issue once and for all, for now your best choice
is to edit the generated files, or even better, write a simple app or a
perl script that strips out all redundant classes generated from the
WSDL. There's an MSDN article that describes the edits you need [0].

The use of remoting is strongly discouraged [1] at this point with
respect to future interoperability issues and a programming model that
tempts developers to develop strongly coupled systems based on the
distributed object metaphor. Personally, I like the .NET Remoting
framework, and I am somewhat disappointed to see such a fine framework
go away, but knowing the issues ahead I can no longer recommend building
new distributed systems on .NET Remoting. At this point .NET Remoting
should strictly be used for intra-process/cross app domain scenarios.

HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko

[0]
http://msdn.microsoft.com/library/en...vice07162002.a
sp

[1] http://weblogs.asp.net/cschittko/arc...27/143388.aspx
-----Original Message-----
From: Picho [mailto:SP********@telhai.ac.il]
Posted At: Sunday, January 02, 2005 12:31 PM
Posted To: microsoft.public.dotnet.framework.webservices
Conversation: web service returned object type problem
Subject: web service returned object type problem

Hi all.

I have a webservice and a windows app.
both of them reference the same class library called

WebServiceTest.Core
that defines a class called Class1.

the webservice exposes a method that looks like this:

[WebMethod]
public WebServiceTest.Core.Class1 GetClass1()
{
return new WebServiceTest.Core.Class1();
}

the windows app has a web reference to the webservice (and a reference

to
the class library).
I want (and even expected) the web-method to return a
WebServiceTest.Core.Class1 object but instead it returns a
WebServicesTest.Client.localhost.Class1 where:
WrbServicesTest.Client is the windows app namespace
localhost is the name of the webreference to the web service
Class1 is some generated class that represents the return type.

my question is simple:

I need the original object. this is why both webservice and windows

app
reference the shared assembly...
what can I do?
what am I doing wrong?

thanx,

Picho


Nov 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.