Un mot d'avertissement, mon expérience cela vient de développer pour Windows Phone 7, donc cela pourrait être légèrement différent de Silverlight normale 3.
JaredPar a souligné le CLR Silverlight est incompatible avec CLR normal. Cela n'est pas correct à 100% car les assemblys compilés en tant que bibliothèques Windows fonctionneront toujours sous Silverlight en supposant qu'ils utilisent des API prises en charge. Vous pouvez modifier manuellement le projet Silverlight et ajouter une référence à l'assembly .NET normal. Notez que vous pouvez uniquement ajouter une référence à un assembly compilé et non au projet. L'application silverlight sera compilée et exécutée, mais dès qu'elle essaie d'utiliser une classe qui n'est pas présente dans Silverlight, vous obtenez une erreur d'exécution.
Pour démontrer la différence dans les API, consultez les captures d'écran suivantes. Comme vous pouvez le voir, les deux assemblages ont des API communes, mais celle de Silverlight en manque. Dès que votre assembly tente de toucher ces API, l'application devient BOOM!
complète .NET 4.0 mscorlib (espace de noms System.serialization):
Full .NET 4.0 mscorlib http://img188.imageshack.us/img188/2131/fullmscorlib.png
Silverlight 3 mscorlib (espace de noms System.serialization):
Silverlight 3 mscorlib http://img526.imageshack.us/img526/4254/sl3mscorlib.png
L'inconvénient de relier un ensemble de .NET complet est que vous ne sauriez pas avant l'exécution quelles API ne sont pas supportées. Compte tenu du fait que certaines API système prises en charge peuvent utiliser une API système non prise en charge, il n'existe pas de moyen facile de résoudre ce problème à l'avance.
Il y a des choses que vous pouvez faire pour faciliter le développement parallèle. L'approche recommandée par Microsoft est d'avoir un projet distinct pour .NET et Silverlight qui partagent le même code source. Vous pouvez le faire manuellement en ajoutant des fichiers en tant que liens vers le projet. C'est un peu un cauchemar de maintenance, mais au moins la plupart des erreurs seront capturées au moment de la compilation.
Alors maintenant, quand vous compilez quelque chose qui fait référence API manquant dans Silverlight vous obtenez une erreur:
public class SerializableExample: IEquatable<string>, System.Runtime.Serialization.ISerializable
{
}
error CS0234: The type or namespace name 'ISerializable' does not exist in the namespace 'System.Runtime.Serialization' (are you missing an assembly reference?)
Avec l'aide de la compilation conditionnelle (a-la bonne ol » C/C++ jours), vous pouvez désactiver des choses qui ne sont pas pris en charge:
public class SerializableExample: IEquatable<string>
#if !SILVERLIGHT
, System.Runtime.Serialization.ISerializable
#endif
{
}
Microsoft fournit également un outil de liaison de projet qui permet une maintenance automatique des projets qui ont des fichiers liés. Malheureusement, la version actuelle ne fonctionne pas sur VS2010, vous pouvez probablement compiler la source et y arriver, mais je n'ai pas essayé.
http://msdn.microsoft.com/en-us/library/dd458870.aspx
lien de téléchargement direct:
http://download.microsoft.com/download/6/3/8/6382E28D-2EBD-4A4E-BB76-6F425E1C9DB9/MicrosoftPracticesProjectLinkerFeb2009.msi
Cette Microsoft page décrit mult-ciblage dans les moindres détails.
Donc, je préfèrerais ajouter la façade de service Web à ma couche de gestion et l'utiliser pour communiquer entre l'application Silverlight et le back-end? – norbertB
@norbertB oui, cela semble être une bonne approche ici. – JaredPar
Cela est tout à fait vrai, mais si vous voyez le deuxième lien dans mon article, quelqu'un a trouvé une façon astucieuse de convertir très facilement des assemblages .NET (bureau) compilés en fichiers Silverlight. Vous devez cependant faire attention au code que vous utilisez dans l'assemblage (et peut-être utiliser des instructions conditionnelles). – Noldorin