I'm using some generic classes as data containers, and am using them to pass data to and from a wcf service. Because of the way WCF mangles generic names on the client side into a class named something like "ListOfBlah231546797646", I'm adding a reference to the real assembly as a "KnownType".
Silverlight needs to consume these services, but can only reference "silverlight assemblies". I've moved the classes to their own "silverlight assembly" and can reference them from silverlight, but when the service runs I get a "cannot find referenced assembly" error on the System.Runtime.Serialization assembly.
It turns out that Silverlight has it's own set of binaries, all labelled version 2.0.5.0. These aren't in the service's GAC and therefore the exception is thrown.
Because of this I can't reference my "Silverlight Assembly" from my service's code. Is there any way I can get around this issue, making the two flavors cross compatible when they get serialized?
This question is similar, but none of the answers help. Any ideas? similar question
The way I share code between Silverlight and normal CLR, is to use the "add as link" feature with C# projects. So it ends up looking 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 get compiled. The annoying part is where the Silverlight framework doesn't line up. (WCF has some parts that don't exist in SL.) In that case, you'll need to use the preprocessor "#if SILVERLIGHT" to make the code target both platforms.
This has worked pretty well so far. This way, I can write code, test with VSTS, but still have it work on SL from the same source. A few tips:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With