Compartiendo ensambles entre Silverlight y "plain vanilla" .Net

Question

Estoy utilizando algunas clases genéricas como contenedores de datos, y los estoy usando para pasar datos hacia y desde un servicio wcf. Debido a la forma en que WCF manipula los nombres genéricos del lado del cliente en una clase llamada algo así como "ListOfBlah231546797646", agrego una referencia al ensamblaje real como un "Tipo Conocido".

Silverlight necesita consumir estos servicios, pero solo puede hacer referencia a "conjuntos Silverlight". He movido las clases a su propio "ensamblaje Silverlight" y puedo hacer referencia a ellas desde Silverlight, pero cuando se ejecuta el servicio aparece el error "no se puede encontrar el ensamblaje al que se hace referencia" en el ensamblado System.Runtime.Serialization.

Resulta que Silverlight tiene su propio conjunto de binarios, todos etiquetados con la versión 2.0.5.0. Estos no están en el GAC del servicio y, por lo tanto, se lanza la excepción.

Debido a esto, no puedo hacer referencia a mi "Ensamblaje de Silverlight" desde el código de mi servicio. ¿Hay alguna forma de evitar este problema, haciendo que los dos sabores se vuelvan compatibles cuando se serialicen?

Esta pregunta es similar, pero ninguna de las respuestas ayuda. ¿Algunas ideas? similar question

Answer 1

La forma en que comparto el código entre Silverlight y CLR normal, es usar la función "agregar como enlace" con proyectos de C#. Así que termina pareciéndose a esto:

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

Luego VS funciona bien y se compilan los dos juegos de códigos. La parte molesta es donde el marco de Silverlight no se alinea. (WCF tiene algunas partes que no existen en SL). En ese caso, deberá usar el preprocesador "#if SILVERLIGHT" para que el código se oriente a ambas plataformas.

Esto ha funcionado bastante bien hasta ahora. De esta forma, puedo escribir código, probar con VSTS, pero todavía tengo que trabajar en SL desde la misma fuente.Algunos consejos:

• Siempre edite desde el proyecto SL - de esta manera el editor limitará a SL, y no obtendrá sorpresas más adelante.
• A veces tiene que cerrar el archivo abierto para que Intellisense actualice en el otro proyecto.

Answer 2

Hay dos maneras en que he hecho esto en el pasado.

Primero y más fácil. Agregue el servicio WCF como una referencia de servicio en Silverlight. Esto se encargará de regenerar todas las bibliotecas de clases y actualizarlas cuando sea necesario.

En segundo lugar, almacene dos copias de las clases, una en Silverlight y otra en .net 3.5 clr. Luego, asegúrese de que los nombres de los DataContract y los espacios de nombres coincidan. Si agrega ServiceReference en Silverlight, en el explorador, vea la carpeta ServiceReference y mire el archivo Reference.cs, verá las clases generadas y podrá copiarlas.

Answer 3

No estoy seguro de si es posible en su escenario, pero ¿ha pensado en proporcionar sus objetos serializados como Json a su cliente Silverlight? Luego, en su aplicación Silverlight puede usar el JsonObject en Silverlight. De esta forma, evitará tener otro conjunto de objetos modelo en su aplicación Silverlight.

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

El ejemplo es de this msdn sample

Lo bueno de este enfoque es también que usted tiene el apoyo de LINQ en Silverlight, y esto puede ser usado por sus clientes ajax también. También es más seguro que exponer sus objetos reales a la aplicación Silverlight que se ejecuta en el cliente.