Quelles différences existent dans DevForce entre les plates-formes Silverlight et non-Silverlight?

Question

Nous avons récemment rencontré un bogue dans notre code provoqué par une différence subtile dans le comportement de DevForce sous Silverlight par rapport aux environnements non-Silverlight. Nous avons découvert à la dure que lorsque DevForce déclenche un événement 'toutes les propriétés ont changé' dans Silverlight, il le fait en utilisant string.Empty dans l'événement PropertyChanged. Toutefois, dans non-Silverlight null est utilisé à la place. Ce n'était pas si difficile de notre part - nous aurions probablement dû faire attention à null ou string.Empty tout le long. Mais cela nous a inquiétés s'il y avait d'autres différences subtiles comme celle-ci que nous devrions surveiller.

Y at-il d'autres différences connues entre Silverlight et non-Silverlight comme ceci? Évidemment, il y a quelques différences telles que Silverlight ne permettant pas les requêtes synchrones ... mais cela est bien documenté. Je suis à la recherche de petites choses comme celle-ci qui pourraient casser le code qui fonctionnait auparavant bien dans Silverlight.

Answer 1

Désolé, vous avez rencontré le problème PropertyChanged. Cette divergence est en fait due à un ancien bogue dans le DataForm SL, mais il n'a jamais été ré-adressé dans DevForce parce que la documentation MS dit que les deux null et la chaîne vide font la même chose. FWIW, DF utilise la chaîne vide ici dans tous les environnements .NET non complets.

Nous n'avons aucune documentation sur ces différences subtiles. En général, la plupart des différences d'environnement entraînent une surface différente, généralement avec une API réduite. Ainsi, comme vous l'avez noté, les méthodes synchrones sont uniquement trouvées dans les assemblys .NET, alors que vous trouverez des API liées à XAP dans les assemblys SL. D'autres fonctionnalités «manquantes» ou modifiées seraient des choses comme la gestion des fichiers d'E/S et des fichiers .config.

En général, DF tente de rationaliser les API et les comportements dans les environnements, bien qu'il puisse y avoir des différences subtiles ou des impacts sur les performances dans les implémentations sous-jacentes. Par exemple, WCF, composition (MEF), sérialisation et réflexion sont quelques domaines que nous avons trouvés ne fonctionnent pas toujours de la même manière dans tous les environnements, bien que nous ayons essayé de les atténuer dans DevForce afin que les applications ne voient pas le problèmes. DF possède également des implémentations shim/dummy pour certains attributs (principalement pour ODATA et les annotations de données) dans des environnements non-NET, ce qui peut poser des problèmes si vous attendez les types réels.

J'ai analysé quelques différences qui pourraient ne pas être évidentes: 1) un constructeur sans paramètre est requis lors du clonage dans non.NET, 2) la validation à la compilation de l'utilisation des attributs ProvideEntityAspect et ProvideComplexAspect est effectuée uniquement dans .NET, 3) tente de crypter/décrypter avec le jeu de paramètres FIPS lancera une exception NotSupportedException dans non.NET.

Il existe également des différences dans la prise en charge de la conception. Dans SL, des exceptions bizarres de sécurité et de sérialisation seront générées par VS lors de l'utilisation de l'ECS ou à l'aide de données de conception basées sur un premier modèle de code.

Je devrais également noter que si vous faites des tests unitaires .NET de votre code SL, vous ne pouvez pas supposer que le code fonctionnera également dans SL. Vous avez vraiment besoin de tester dans SL aussi pour éviter les surprises.

Si vous avez des questions sur des zones spécifiques de DevForce ou si vous rencontrez des différences d'environnement inattendues, faites-le nous savoir.