Sharing assemblies between Silverlight and plain vanilla .Net

I use some common classes as data containers, and use them to transfer data to and from the wcf service. Due to the way WCF manages client-side generic names in a class named "ListOfBlah231546797646", I add a link to the actual assembly as "KnownType".

Silverlight should consume these services, but can only refer to Silverlight assemblies. I moved the classes to my "silverlight" assembly and can refer to them from silverlight, but when the service is running, I get the error "I cannot find the assembly reference" on the System.Runtime.Serialization assembly.

It turns out that Silverlight has its own set of binaries, all with a version 2.0.5.0 tag. They are not in the GAC service, and therefore an exception is thrown.

Because of this, I cannot reference my Silverlight Assembly from my service code. Is there a way around this problem by making these two options compatible with each other when they are serialized?

This question is similar, but none of the answers help. Any ideas? similar question

+6
silverlight wcf
source share
3 answers

The way code is exchanged between Silverlight and the regular CLR is to use the add as a link feature with C # projects. So it looks like this:

| SilverlightLib | File1.cs | File2.cs | ClrLib | File1.cs <as link> | File2.cs <as link> 

Then VS works fine, and both sets of code are compiled. The annoying part is where the Silverlight structure does not line up. (WCF has some parts that do not exist in SL.) In this case, you need to use the "#if SILVERLIGHT" preprocessor to make the code targeted for both platforms.

So far this has worked very well. Thus, I can write code, test VSTS, but still work on SL from the same source. A few tips:

  • Always edit your SL project - this way, the editor will restrict SL and you won’t get any surprises later.
  • Sometimes you need to close an open file for Intellisense to update in another project.
+3
source share

In the past, I have done this in two ways.

The first and easiest. Add the WCF service as a ServiceReference in Silverlight. This will take care of restoring all class libraries and updating them if necessary.

Secondly, save two copies of the classes, one in silverlight and one in .net 3.5 clr. Then make sure the DataContract Names and Namespaces match. If you add ServiceReference to silverlight, then in the explorer view the ServiceReference folder and look at the Reference.cs file, you will see the created classes and you can copy them.

+1
source share

Not sure if this is possible in your scenario, but have you thought about serializing your objects as Json for your silverlight client? Then in a silverlight application you can use JsonObject in silverlight. This way you avoid using a different set of model objects in the silverlight application.

 JsonObject user = (JsonObject)JsonObject.Load(responseStream); bool isMember = user["IsMember"]; string name = user["Name"]; int age = user["Age"]; 

Example from this sample msdn

The good thing about this approach is also that you have linq support in silverlight, and this can be used by your ajax clients as well. It is also safer than exposing your real objects to a silverlight application running on the client.

0
source share

All Articles