Condivisione di assembly tra Silverlight e "plain vanilla" .Net

Question

Sto utilizzando alcune classi generiche come contenitori di dati e li sto utilizzando per trasferire dati da e verso un servizio wcf. A causa del modo in cui WCF gestisce nomi generici sul lato client in una classe denominata "ListOfBlah231546797646", sto aggiungendo un riferimento all'assembly reale come "KnownType".

Silverlight deve consumare questi servizi, ma può solo fare riferimento a "Silverlight Assemblies". Ho spostato le classi sul proprio "assembly silverlight" e posso farvi riferimento da silverlight, ma quando si esegue il servizio ottengo un errore "Impossibile trovare l'assembly di riferimento" sull'assembly System.Runtime.Serialization.

Si scopre che Silverlight ha il proprio set di file binari, tutti etichettati versione 2.0.5.0. Questi non sono nel GAC del servizio e pertanto viene generata l'eccezione.

Per questo motivo non posso fare riferimento al mio "Silverlight Assembly" dal codice del mio servizio. C'è un modo per aggirare questo problema, rendendo i due sapori compatibili quando vengono serializzati?

Questa domanda è simile, ma nessuna delle risposte è di aiuto. Qualche idea? similar question

Answer 1

Il modo in cui condivido il codice tra Silverlight e CLR normale, consiste nell'utilizzare la funzione "aggiungi come collegamento" con i progetti C#. Quindi si presenta così:

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

Quindi VS funziona correttamente ed entrambi i set di codice vengono compilati. La parte fastidiosa è dove il framework Silverlight non si allinea. (WCF ha alcune parti che non esistono in SL.) In tal caso, sarà necessario utilizzare il preprocessore "#if SILVERLIGHT" per rendere il codice target a entrambe le piattaforme.

Questo ha funzionato abbastanza bene finora. In questo modo, posso scrivere codice, testare con VSTS, ma farlo funzionare su SL dalla stessa fonte.Alcuni suggerimenti:

• Modifica sempre dal progetto SL - in questo modo l'editor limiterà a SL, e non si otterranno sorprese in seguito.
• A volte è necessario chiudere il file aperto per Intellisense da aggiornare nell'altro progetto.

Answer 2

Ci sono due modi in cui ho fatto questo in passato.

Primo e più semplice. Aggiungere il servizio WCF come servizio di riferimento in Silverlight. Questo si prenderà cura di rigenerare tutte le librerie di classi e di aggiornarle quando necessario.

In secondo luogo, memorizzare due copie delle classi, una in silverlight e una in .net 3.5 clr. Quindi assicurarsi che i nomi e gli spazi dei nomi DataContract corrispondano. Se si aggiunge ServiceReference in silverlight, in Esplora risorse viene visualizzata la cartella ServiceReference e il file Reference.cs visualizza le classi generate e possono copiarle.

Answer 3

Non sono sicuro se è possibile nel tuo scenario, ma hai pensato di fornire gli oggetti serializzati come Json al tuo client silverlight? Quindi nella tua app silverlight puoi usare lo JsonObject in silverlight. In questo modo eviti di avere un altro set di oggetti modello nella tua app silverlight.

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

L'esempio è da this msdn sample

La cosa bella di questo approccio è anche di avere il supporto di LINQ in Silverlight, e questo è utilizzabile dai vostri clienti Ajax pure. È anche più sicuro di esporre i tuoi oggetti reali all'app silverlight in esecuzione sul client.