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.

 

[Sheng Jiang[MVP]]

You can serialize your class, pass it as an string or XmlDocument, and
deserialze it at the other end.

It is suggested to add a version number in your class, so you can handle
multiple versions of your classes..

 

[Bradley Plett]

Wow! That was quick!

Can you provide sample code?

Thanks!
Brad.

 

[Sheng Jiang[MVP]]

To make your class serializable, see
Introducing XML Serialization
http://msdn2.microsoft.com/en-us/library/182eeyhh(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.

 

[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.

 

[Sheng Jiang[MVP]]

The object from the web service will be System.String or
System.Xml.XmlDocument.

 

[Bradley Plett]

No, the object from the web service is strongly typed, and has a
namespace. In fact, it has all the properties of the client object,
but without the methods. I don't feel like I'm getting much closer
here.

Brad.

 

[Sheng Jiang[MVP]]

Add serialization support to your business layer classes
CHANGE your web service parameters and/or return values to string or
XmlDocument
Serialize your business layer object to string or XmlDocument before calling
your web service
In your webservice, deserialize the string or the XmlDocument to a business
layer object

If you need to return a business layer object, serialize it to string or
XmlDocument and return
In your client App, deserialize the string or the XmlDocument to a business
layer object.

 

[Bradley Plett]

In my opinion, that's more complicated and more kludgy that what I'm
already doing! Surely there must be an easier way.

Perhaps if I simply asked the following question: how does one change
the namespace of an object?

Brad.

 

[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/subscriptions/managednewsgroups/default.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/subscriptions/support/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.

 

[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/tutorial...d78-ff541dfbcb56/net-reflection--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.

 

[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/microsoft.public.dotnet.framework.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.