Toujours en direct du TechEd 2007, mon compte-rendu instantané des sessions. Dans cette session, Daniel Moth nous explique comment, avec un minimum d'efforts, écrire du code qui fonctionne sur les deux plateformes.
Pourquoi
Il y a plein de bonnes raisons pour faire ça:
- c'est cool
- on peut atteindre plus de clients
- on réutilise les outils du PC pour améliorer notre façon de développer "mobile"
Différences
Visual Studio for devices: ce sont les mêmes outils.
C#, VB.NET sont pris en charge, mais pas les autres langages. Il y a même prise en charge de LINQ avec la V3.5.
Mais il n'y a pas
- un serveur ASP.NET
- Code Access Security
- Sérialisation binaire
- Reflection Emit
- Configuration
- Codedom
- WPF, WF, LINQ to SQL/Entities
En outre, des classes et contrôles n'ont pas certaines propriétés (exemple: Button.Image).
Quelques classes sont spécifiques au NETCF (1.0 et encore plus en 2.0): HardwareButton, LogFont, MobileDevice.Hibernate, ...
En outre, Windows Mobile 5.0 / 6 ont leurs propres classes, qui font partie de la plateforme mais pas du .NET Compact Framework.
Le CLR est simplifié (Garbage Collector et JIT plus simples), mais cela ne nous touche pas directement.
Vu les différences entre machines, ce n'est pas une bonne idée de partager la même UI. Par contre on peut mettre le reste en commun.
Partage du code
Assembly desktop: à ne pas faire
Pour commencer, il n'est pas recommandé de réutiliser sur du .NET Compact Framework un assembly généré pour le desktop.
C'est techniquement possible en ajoutant une référence manuelle à l'assembly, mais on obtient une TypeLoadException. A éviter, donc.
Sur un projet où cela a été fait par erreur, on peut s'en rendre compte lors du déploiement vers la machine avec Visual Studio: il prend du temps car les assemblys desktop du GAC sont déployés aussi!
Assembly compact vers desktop : retargetable
Démo: une GUI faite pour le Compact Framework est lancée sur le desktop après avoir été compilée pour le .NET Compact Framework, et... ça fonctionne!
Cela s'appelle le Re-Targeting. Il y a un attribut "retargetable" sur les assemblys générés pour le .NET Compact Framework, qui permet au CLR de charger au runtime une autre DLL qui correspond à celle qui était référencée.
Il y a bien sûr des problèmes, et notamment quand on fait des appels de plateforme. Mais pour les éviter, on peut tester Environment.OSVersion.Platform (c'est une énumération).
Mais la protection avec un "if" ne fonctionne pas toujours car le JITter cherche tous les types utilisés dans une méthode. On peut dans ce cas mettre le code d'un "if" dans une autre méthode pour ne pas avoir le problème. Mais cela demande du refactoring, que l'on n'a pas forcément envie de faire (sans même parler de l'inlining par le compilateur qui pourrait annuler cela).
Assembly compact vers desktop : conditional compilation
On utilise le #if, et on partage le code mais pas les binaires.
On peut pour cela créer un projet desktop et y ajouter les fichiers du compact en prenant soin d'ajouter des liens, pas une copie des fichiers.
Cette approche avec Visual Studio permet de bénéficier d'une vérification des types dès la compilation.
Comments