Return data structure defined in Class library from WCF Web Service

[AliR \(VC++ MVP\)]

Hi everyone,

I'm writing a silverlight 2.0 application that uses a web service. The web
service is a WCF web service and it uses a class library that I have
written. When I add a method to the webservice that uses/returns an object
that was defined in the class library all hell breaks loose.
What happens is that my service object no longer has the client class
anymore, all it shows are the objects that are being used from the class
library.

Not sure if I'm explaining it correctly since I'm not very .Net savvy.

Basically when I used to type the service name followed by . it would get
the list which included the service client that I would use to communicate
with the service, now there is no such thing instead it only lists the 3 or
4 classes that the service returns that were defined in the class library.

Am I doing something wrong here? Or do I have to define everything that is
going to be returned in the service.

AliR.

 

[Marc Gravell]

Ideally, yes: your WCF layer would define all the types used in that
API via data-contracts ([DataContract]) or similar.

For full-.NET to full-.NET, one option is assembly sharing (i.e.
cheating by placing the service contract and entities in a dll that
both client and server consume), and use that dll at both ends - but
the problem is that it doesn't work if the client/server are different
architectures. And Silverlight qualifies as "different". So yes, I'd
make sure that all the objects you use in the WCF stack are properly
defined as data-contracts, and let "mex" do the rest.

Marc

 

[Marc Gravell]

In short - serialization. WCF (especially when used from Silverlight)
essentially uses xml serialization. What does a bitmap look like in
xml? There are, however, known ways of serializing raw bytes - hence a
byte[] or Stream will be fine. The Bitmap approach *might* have worked
(maybe, at a push) using NetDataContractSerializer and assembly-
sharing. Neither is an option for Silverlight, so you can rule that
out.

Marc