Comment puis-je écrire une bibliothèque de classe .NET que je peux recompiler pour le cadre régulier .NET 3.5, ou le cadre compact de .NET 3.5?
3 Réponses :
Les deux cadres ne sont pas compatibles binaires *, malheureusement, mais ne laissez pas cela vous arrêter.
Créer deux projets dans votre solution (un projet de bibliothèque de classe normale et un projet de bibliothèque de classe cadre compact), et Ajoutez tous les fichiers d'un projet à l'autre comme links en cliquant sur "Ajouter un fichier existant", puis cochez la case "Ajouter en tant que lien" sur la boîte de dialogue Fichier. maintenant Vous avez seulement un ensemble de code source à entretenir, mais votre solution construira les deux dlls en même temps. Si vous avez un code dans un fichier spécifique au cadre de bureau et ne fonctionnera pas sur Le cadre compact, vous pouvez l'envelopper dans une directive compilateur (au moins en C #) comme ceci:
J'ai été exécuté avec succès des applications de bureau - et des sites ASP.NET - les assemblages de cadre compact de référence pour un certain temps maintenant. On dirait qu'il n'y a pas de problème avec ce que ce que ce soit jamais ...
En fait ... cela signifie-t-il que vous devez installer le cadre compact sur vos machines cible? Ou les assemblées NETCF utilisent-elles le cadre de bureau si elle est disponible?
Non, le cadre compact n'a pas besoin d'être installé sur les machines cible. Donc, les assemblages de bureau doivent être utilisés. Si je me souviens, il y avait un document assez complet sur le MSDN sur cette question, mais je ne peux pas le trouver maintenant ...
Oui, il fonctionne simplement sous l'édition de bureau de CLR. Par conséquent, il convient de connaître les différences entre FF et CF si vous partagerez du code entre les deux. J'ai une liste très incomplète d'ici: Stackoverflow.com/questions/342576/...
> Les deux cadres ne sont pas compatibles binaires >
En réalité, la version de bureau peut charger et exécuter des assemblages CF.
Ah oui c'est vrai. +1 et je vais modifier ma réponse.
DotNetCF3.5 est compatible avec Desktopversion. Dans DotNetCF3.7, ce n'est plus mais il est compatible avec Silverlight. Voir blogs.msdn.com/b/abhinaba/archive/2010/03/18/... pour plus de détails
Sérieusement, je ne sais pas pourquoi la réponse supérieure est si top. Vous n'avez pas besoin de deux projets distincts du tout. De plus, je ne suis pas amoureux des directives de pré-processeur, ils sont laids et nécessitent des connaissances supplémentaires sur le projet lors de la lecture avec les paramètres de construction. Il est beaucoup plus joli d'externaliser tous les morceaux et morceaux incompatibles à une interface (iplaformServices ou comme vous pouvez même vous demander simplement de demander: P>
if(Environment.OSVersion.Platform == PlatformID.WinCE)
{
// winCE specific
}
else
{
// desktop specific
}
Les directives de préprocesseur signifient que le code ne se retrouve pas dans l'assembly s'il n'est pas requis (ou pris en charge) sur cette plate-forme. C'est important sur le cadre compact où vous souhaitez que vos assemblées soient aussi petites que possible.
Point équitable. Si l'espace disque et la mémoire sont pressants en appuyant sur les préoccupations, utilisez une seule commande de préprocesseur pour générer votre iplatformServices. Les avoir jonchées pendant une base de code peut être hellish, alors je ne recommande pas cette route.