Introduction au Compact Framework .NET

Le Compact Framework .NET possède des ressemblances et des différences avec le .NET Framework.

• Common Language Runtime : dans les deux infrastructures, les CLR (Common Language Runtime) tirent parti de l'exécution de code managé, de la compilation de code juste-à-temps (JIT, Just In Time) et du garbage collection (Garbage Collector). Ils prennent en charge la spécification de langage commun (CLS, Common Language Specification).
• Assemblys et formats de fichier : dans les deux infrastructures, les applications utilisent les assemblys.
• Prise en charge de plusieurs langages : l'interopérabilité interlangage fait partie intégrante du .NET Compact Framework. Visual C# et Visual Basic .NET sont les deux premiers langages pris en charge.
• Respect des normes : la technologie de base implémentée dans les deux infrastructures est conforme à la norme CLI (Common Language Infrastructure) de l'association ECMA (European Computer Manufacturers Association).

Il existe beaucoup de différences entre le Compact Framework .NET et le Framework .NET. En voici une liste non exhaustive ?

• Tableaux : au contraire de certains langages, le Common Language Runtime ne prend pas en charge les limites inférieures autres que zéro et lève une exception MissingMethodException si le premier élément d'un tableau n'est pas zéro.
• ASP.NET : le Compact Framework .NET est essentiellement une plate-forme de client élaboré et ne prend pas en charge ASP.NET.
• Assemblys et GAC (Global Assembly Cache) : dans sa version actuelle, le .NET Compact Framework ne prend pas en charge les assemblys composées de plusieurs modules, mais prend en charge les assemblys satellites.
• Classes : le .NET Compact Framework prend en charge un sous-ensemble de la bibliothèque de classes .NET Framework.
• COM interop et fonctions de rappel : le Compact Framework .NET n'assure pas l'interopérabilité avec les objets COM, mais vous pouvez utiliser PInvoke (platform invoke) pour accéder à des fonctions DLL natives qui, à leur tour, peuvent appeler des objets COM.
• Répertoire en cours : la fonctionnalité de répertoire en cours est absente sur les périphériques qui exécutent Windows CE .NET ; par conséquent, le .NET Compact Framework ne prend pas en charge les méthodes Directory.GetCurrentDirectory et Directory.SetCurrentDirectory.
• Données : le Compact Framework .NET fournit une implémentation de sous-ensemble de ADO.NET et inclut le fournisseur de données SQL Server CE .NET. L'espace de noms System.Data.OleDb n'est pas pris en charge.
• Types de données et précision en virgule flottante : seule Math.Round(double a) est prise en charge ; Math.Round(double a, double b) n'est pas prise en charge.
• Délégués : les délégués asynchrones, en particulier les méthodes BeginInvoke et EndInvoke, ne sont pas pris en charge.
• Événements : le .NET Compact Framework prend en charge les événements GotFocus et LostFocus, mais non les événements Activated et Deactivated.
• Installation et fichiers CAB : vous pouvez utiliser des fichiers CAB et créer des applications MSI pour distribuer vos applications.
• Test des performances : le .NET Compact Framework ne prend en charge ni le profilage de code, ni le fichier Perfmon.exe du Moniteur système.
• Réflexion : le .NET Framework ne prend pas en charge l'espace de noms System.Reflection.Emit.
• Sérialisation : pour des raisons de taille et de performances, le .NET Compact Framework ne prend en charge ni la sérialisation binaire à l'aide de BinaryFormatter, ni la sérialisation SOAP à l'aide de SoapFormatter.
• Minuteries : les méthodes Timer.Start et Timer.Stop ne sont pas prises en charge, mais vous pouvez démarrer et arrêter une minuterie en affectant à la propriété Timer.Enabled la valeur true or false.

Le Compact Framework .NET est une implémentation de sous-ensemble compatible du Framework .NET et du Common Language Runtime. Une application Compact Framework .NET peut s'exécuter sur le Framework .NET, avec les importantes exceptions suivantes :

• les assemblys Compact Framework .NET sont signés avec des paires de clés de nom fort différentes, ce qui permet au Common Language Runtime de les distinguer de celles de leurs homologues dans le Framework .NET ;
• il se peut que les futures versions du Framework .NET incluent une stratégie de liaison pour les applications Compact Framework .NET, en remplaçant s'il y a lieu des applications compactes exécutées sur un ordinateur personnel par des assemblys Framework .NET ;
• si vous faites référence à des fonctionnalités spécifiques au Compact Framework .NET, par exemple des contrôles d'interface utilisateur propres au Pocket PC, votre programme ne pourra pas se lier au Framework .NET.

Chaque application Compact Framework .NET s'exécute dans une construction de runtime appelée domaine d'application, qui est semblable à un processus de système d'exploitation. LeCompact Framework .NET fait en sorte que toutes les ressources managées utilisées par une application en cours d'exécution soient libérées ou rendues au système d'exploitation hôte lorsque l'application se termine.

Les domaines d'application offrent la plupart des avantages des processus, par exemple l'isolation des problèmes, la robustesse accrue et la sécurité, sans exiger de prise en charge par le système d'exploitation hôte sous-jacent.

Le Compact Framework .NET prend en charge plusieurs domaines d'application. Vous pouvez spécifier un assembly dans le constructeur d'une classe. Ensuite, vous pouvez utiliser la classe System.AppDomain.ExecuteAssembly pour démarrer un nouveau domaine d'application. Le nouveau domaine d'application charge ses propres copies des bibliothèques DLL, des structures de données et des pools de mémoire du Common Language Runtime. Plusieurs domaines d'application peuvent exister dans un même processus du système d'exploitation.

Le Compact Framework .NET détermine le moment où doit s'exécuter le garbage collection. Le garbage collection peut avoir lieu dans un seul domaine d'application ou dans tous les domaines d'application. Ceci empêche un domaine d'application d'utiliser trop de mémoire au détriment des autres.

L'une des forces importantes du Compact Framework .NET réside dans son utilisation efficace des ressources, notamment la mémoire vive volatile.

Le Compact Framework .NET a été optimisé pour les systèmes présentant les caractéristiques suivantes :

• alimentation par batterie ;
• un espace de travail compris entre 128 Ko et 1 Mo en RAM dynamique ;
• un disque dur facultatif.

Le Compact Framework .NET utilise la mémoire système disponible avec modération. Il n'accède pas à la mémoire vive avant que vous n'exécutiez une application. De plus, le Compact Framework .NET libère la mémoire vive dès que vous quittez les programmes. Il n'est pas nécessaire que le système d'exploitation natif possède ses propres fonctionnalités de protection de la mémoire. Des exceptions sont levées systématiquement en cas d'accès à une mémoire non affectée.

La mémoire vive est utilisée pour stocker les structures de données dynamiques et le code compilé juste-à-temps. Le Compact Framework .NET utilise la mémoire vive disponible jusqu'à une limite spécifiée par le périphérique pour stocker dans un cache le code généré et les structures de données, puis il libère la mémoire en temps opportun.

Le Compact Framework .NET fournit les fonctionnalités XML de base, notamment le modèle objet de document (DOM, Document Object Model) XML. Pour économiser de la place, les composants XML suivants ne sont pas pris en charge :

• validation de schéma XML ;
• classe XmlDataDocument ;
• requêtes xpath, notamment les méthodes de sélection de nœuds qui admettent des paramètres xpath ;
• transformation XSLT (Extensible Stylesheet Language Transformation).

De plus, le Compact Framework .NET n'autorise pas l'emploi de chemins d'accès relatifs conformément au schéma URI file://. Spécifiez un chemin d'accès absolu lorsque vous utilisez la méthode DataSet.ReadXML, qui admet comme paramètre une chaîne représentant le nom de fichier.

Lorsque vous programmez des applications pour accéder à des données dans le Compact Framework .NET, prenez en compte les points suivants :

• le .NET Compact Framework ne prend pas en charge les classes suivantes : l'espace de noms System.Data.OleDb, la classe System.Data.SqlClient.SqlClientPermission, la classe System.Data.SqlClient.SqlClientPermissionAttribute ;
• l'authentification Windows est prise en charge ; cependant, l'ID utilisateur et le mot de passe employés pour l'authentification dans le contrôleur de domaine doivent toujours être spécifiés dans la chaîne de connexion ;
• System.Data.SqlClient ne peut pas découvrir automatiquement le numéro de port d'une instance nommée de SQL Server qui s'exécute sur un port personnalisé. Pour établir une connexion à un serveur exécuté sur un port personnalisé, vous devez spécifier le numéro de ce port dans la chaîne de connexion après la virgule ;
• les applications utilisant System.Data.SqlClient sur les périphériques Microsoft Windows CE peuvent employer le protocole d'authentification NTLM (Windows NT LAN Manager) au lieu de l'authentification SQL Server.

Vous devez prendre en compte les points suivants lorsque vous programmez des objets graphiques dans le Compact Framework .NET :

• le Compact Framework .NET ne prend pas en charge GDI+. Plusieurs méthodes de la classe Graphics, qui effectuent des opérations complexes de dessin, de remplissage et de transformation, ne sont pas prises en charge. Les chemins, les courbes et les graphismes 2D/3D ne sont pas pris en charge. Toutefois, le .NET Compact Framework prend en charge les principales primitives de dessin et les méthodes de remplissage correspondantes : Ellipse, Line, Image, Polygon, Rectangle, String et Region ;
• seule la transparence définie par des clés de couleurs est prise en charge. La fusion alpha (fusion pixel par pixel des données de couleur de la source et de l'arrière-plan) n'est pas prise en charge. De ce fait, les deux paramètres de la méthode ImageAttributes.SetColorKey doivent indiquer la même couleur ;
• le Compact Framework .NET et le Framework .NET évaluent différemment les comparaisons entre couleurs connues. Dans le Compact Framework .NET, une couleur est considérée comme identique à une couleur connue, par exemple le bleu vert, si elle possède les mêmes valeurs RVB que la couleur connue. Le Framework .NET, quant à lui, évalue ces couleurs comme différentes parce que les couleurs connues contiennent des informations d'identification en plus des valeurs RVB ;
• le Compact Framework .NET ne prend pas en charge le constructeur qui utilise un objet Font existant pour la classe System.Drawing.Font.

Le Compact Framework .NET offre une prise en charge limitée, mais suffisante, des interactions avec le code non managé. À l'instar du .NET Framework, il fournit le mécanisme d'appel de plate-forme (platform invoke) pour appeler le code non managé depuis le code managé, mais avec quelques restrictions au niveau du marshaling des données.

Le Compact Framework .NET ne prend pas directement en charge l'interopérabilité COM, qui permet au code managé d'interagir avec les objets COM à travers des interfaces. Le Compact Framework .NET assure une prise en charge indirecte de COM interop moyennant la programmation avancée de wrappers personnalisés pour appeler des points d'entrée de DLL spécifiques, ce qui permet à des objets managés d'utiliser COM. Le .NET Compact Framework ne permet ni la création d'objets COM en code managé, ni les interactions avec les contrôles ActiveX.

Lorsque vous effectuez un appel de plate-forme (platform invoke), le Common Language Runtime épingle l'objet non managé en mémoire pour la durée de vie de l'appel de méthode. Respectez les instructions suivantes pour gérer la mémoire avec un code non managé dans le Compact Framework .NET :

• allouez toujours la mémoire en code managé avant de passer au code non managé ;
• si le code non managé contient un pointeur vers un composant managé, vous devez épingler l'objet manuellement à l'aide de la structure GCHandle.

Dans le Compact Framework .NET, un appel de plate-forme (platform invoke) comporte trois parties :

• au moment du design, le développeur fournit une description de la fonction non managée à appeler. Cette description inclut le nom du module (fichier DLL), le nom du point d'entrée et la convention d'appel ;
• au moment de la compilation juste-à-temps, le Common Language Runtime extrait ces informations des métadonnées, recherche la DLL contenant la fonction, charge la DLL en mémoire et extrait l'adresse de la fonction. Si le module ou la fonction est introuvable, le Common Language Runtime lève une exception MissingMethodException ;
• au moment de l'exécution, le Common Language Runtime marshale les paramètres du format managé au format non managé avant l'appel de la fonction non managée. Le Common Language Runtime se sert de la déclaration managée de la méthode pour déterminer comment marshaler chaque paramètre.

Pour avoir plus d'informations sur les Dll natives et P/Invoke, regardez ici.