Shared class and namespace issues in web service?

[Bradley Plett]

I have run into this problem occasionally, and have crude ways of
getting around it, but I'm wondering if anyone else has a better, more
elegant solution.

I have a web service and a client application that share a class. For
one of my web service methods, for example, I return an object of the
given class type. However, when I try to cast the object in my
client, I run into a namespace conflict. This makes sense to me, but
if I simply use the object provided from the web service, I lose all
of the methods due to serialization. I don't want to have to use
remoting, but I do want the class methods available to me. I can't do
a direct cast, as I said, due to namespace issues. What's the best
way to handle this? I assume it will include reflection, but I'm no
reflection expert.

I'm sure this has been asked and answered many times, but my quick
scan failed to find the answer.

Thanks!
Brad.

[Bradley Plett]

I believe the issue of namespaces remains. If I serialize the object
from the web service, the namespace persists, making the
deserialization fail (or at least not produce the desired results),
since deserialization is to the client object's namespace. That's why
I was hoping for some sample code that dealt with this issue. Ideas?

Thanks again,
Brad.

On Wed, 18 Jul 2007 15:53:32 -0500, "Sheng Jiang[MVP]"
<sh*********@hotmail.com.discusswrote:

>To make your class serializable, see
Introducing XML Serialization
http://msdn2.microsoft.com/en-us/lib...hh(vs.80).aspx

By the way, it is faster to create typed and properties using XML schema
editor and XSD.exe than typing in C# editor.

[Steven Cheng[MSFT]]

Hi Brad,

Yes, the question you mentioned does be a typical scenario. Actually, for
XML webservice, it is not recommended that client-side and server-side
share the same class implementation, because XML webservice should only
communicate based on WSDL description. Anyway, since your client and
server are both .NET based, that won't matter. To resolve the problem,
one approach I've suggested is manually modify the autogenerated client
proxy class, change the return type (originally is autogenerated from WSDL)
to your own custom classes(also shared at server-side).

Also, one problem here is that when you update the client proxy, your
modification in the proxy source code will be removed. In .NET framework
2.0, there is a partial class feature, so you can add a partial class file
for your client-side webservice proxy and add those webmethods that use
your own class in the partial class file. Thus, the separate partial class
file won't be affected when you update the service proxy. How do you think?

If there is anything unclear or if you have any other more specific
questions, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Bradley Plett]

This sounds promising, but I think I'd need an example to make sense
of it. I am using .NET 2.0, so the partial class is definitely an
option for me.

Brad.

On Thu, 19 Jul 2007 04:23:25 GMT, st*****@online.microsoft.com (Steven
Cheng[MSFT]) wrote:

>Hi Brad,

Yes, the question you mentioned does be a typical scenario. Actually, for
XML webservice, it is not recommended that client-side and server-side
share the same class implementation, because XML webservice should only
communicate based on WSDL description. Anyway, since your client and
server are both .NET based, that won't matter. To resolve the problem,
one approach I've suggested is manually modify the autogenerated client
proxy class, change the return type (originally is autogenerated from WSDL)
to your own custom classes(also shared at server-side).

Also, one problem here is that when you update the client proxy, your
modification in the proxy source code will be removed. In .NET framework
2.0, there is a partial class feature, so you can add a partial class file
for your client-side webservice proxy and add those webmethods that use
your own class in the partial class file. Thus, the separate partial class
file won't be affected when you update the service proxy. How do you think?

If there is anything unclear or if you have any other more specific
questions, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

================================================= =

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

================================================= =
This posting is provided "AS IS" with no warranties, and confers no rights.

[Bradley Plett]

Actually, thanks to Jon Skeet in another thread, I may have found as
elegant a solution as I can hope for. Yes, it may have some issues,
but it works for me! :-)

// the idea for this came from
http://www.eggheadcafe.com/tutorials...--copy-cl.aspx
private static T SetProperties<T, U>(U fromRecord, T toRecord)
{
foreach (PropertyInfo fromField in
fromRecord.GetType().GetProperties())
{
if (fromField.Name != "Id")
{
foreach (PropertyInfo toField in
toRecord.GetType().GetProperties())
{
if (fromField.Name == toField.Name)
{
toField.SetValue(toRecord,
fromField.GetValue(fromRecord, null), null);
break;
}
}
}
}
return toRecord;
}

Thanks!
Brad.

On Thu, 19 Jul 2007 01:11:57 -0600, Bradley Plett
<pl****@newsgroup.nospamwrote:

>This sounds promising, but I think I'd need an example to make sense
of it. I am using .NET 2.0, so the partial class is definitely an
option for me.

Brad.

On Thu, 19 Jul 2007 04:23:25 GMT, st*****@online.microsoft.com (Steven
Cheng[MSFT]) wrote:

>>Hi Brad,

Yes, the question you mentioned does be a typical scenario. Actually, for
XML webservice, it is not recommended that client-side and server-side
share the same class implementation, because XML webservice should only
communicate based on WSDL description. Anyway, since your client and
server are both .NET based, that won't matter. To resolve the problem,
one approach I've suggested is manually modify the autogenerated client
proxy class, change the return type (originally is autogenerated from WSDL)
to your own custom classes(also shared at server-side).

Also, one problem here is that when you update the client proxy, your
modification in the proxy source code will be removed. In .NET framework
2.0, there is a partial class feature, so you can add a partial class file
for your client-side webservice proxy and add those webmethods that use
your own class in the partial class file. Thus, the separate partial class
file won't be affected when you update the service proxy. How do you think?

If there is anything unclear or if you have any other more specific
questions, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

================================================ ==

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

================================================ ==
This posting is provided "AS IS" with no warranties, and confers no rights.

[Steven Cheng[MSFT]]

Thanks for your followup Brad,

Glad that you've got it working. Just to add some further info on the other
approach I mentioned, here is a former thread discussing on the same issue
and I've included some test code snippet and steps about the "manually
change autogenerated proxy class through partial class file" approach:

http://groups.google.com/group/micro...rk.webservices
/browse_thread/thread/b844c512cadd9b28/030faf776ee4969e

Hope this also helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[Bradley Plett]

Thanks! I may try this method sometime too. :-)

Brad.

On Fri, 20 Jul 2007 02:20:42 GMT, st*****@online.microsoft.com (Steven
Cheng[MSFT]) wrote:

>Thanks for your followup Brad,

Glad that you've got it working. Just to add some further info on the other
approach I mentioned, here is a former thread discussing on the same issue
and I've included some test code snippet and steps about the "manually
change autogenerated proxy class through partial class file" approach:

http://groups.google.com/group/micro...rk.webservices
/browse_thread/thread/b844c512cadd9b28/030faf776ee4969e

Hope this also helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.