Le premier site francophone dédié au développement Pocket PC

Comment développer avec .NET pour Pocket PC sans Visual Studio ?
Auteur
Richard Clark
Date 24 janvier 2003
 
   


Introduction

C'est suite à une question de Monsieur LD - personne dont je tairais le nom ainsi que le nom de la société pour laquelle il travaille ;-) - et de Stéphane Sibué (codeppc.com, codeppc.net, etc.) que j'ai décidé d'écrire cet article. La question était simple :

Est-il possible de créer des applications pour Pocket PC avec le Compact Framework sans Visual Studio .NET ?

Traduction : j'ai pas les sous pour me payer Visual Studio .NET, je veux des outils gratuits.

La réponse est : OUI.

Oui vous pouvez développer des applis pour Pocket PC avec le bloc-notes ou autres mais cela nécessite quelques manipulations ou plutôt une connaissance approfondi du fonctionnement du .NET Framework.

J'avoue que comme la question m'a été soumise en pleine animation d'une formation, j'ai eu du mal a répondre immédiatement. Elle réclame bien entendu quelques explications mais elle a l'avantage d'exposer une nouvelle fois en détails tous les mécanismes de .NET et de comprendre l'une des démos faites aux DevDays 2003 montrant un même fichier exécutable tournant sous WinXP, FreeBSD et MacOS 10.2.

La CLI

A la base est la CLI. La CLI est dans le domaine publique, soumise et approuvée comme norme ECMA et ISO. La CLI est une sorte de cahier des charges indiquant ce qu'est un .NET Framework. Elle spécifie bon nombre de chose comme le format des fichiers, ce qu'est un type (classe, interface, objet, etc.), ce qu'est le Langage Intermédiare, etc.

Microsoft a donc crée son propre .NET Framework, répondant au cahier des charges de la CLI, en espérant que ce serait le meilleurs .NET Framework pour Windows. Rien n'empêche une société tierse de créer son propre .NET Framework pour Windows qui concurrence le MS .NET Framework (enfin, y'a du boulot quand même...).

Certains sont en train de créer leur propre .NET Framework pour d'autres plateformes comme le célèbre projet Mono, en Open Source, pour Linux.
Microsoft propose d'ailleurs une implémentation de la CLI qui est librement téléchargeable (ne me posez pas de question sur les problèmes de libre redistribution du produit, j'en sais rien), ou vous avez accès à son code source complet, et qui est implémentable sur WinXP, FreeBSD et MacOS.

Bref, le cahier des charges CLI est publique et dit comment cela doit fonctionner. Parmi ses spécifications, figure notamment le format des fichiers. Il y est dit qu'un exécutable .NET contient plusieurs parties (c'est simplifié mais en gros ça marche comme ça) :

  • Le PE Header indiquant au système d'exploitation qui doit prendre en charge l'exécutable. Pour le MS .NET Framework pour Win32 par exemple, il est indiqué que c'est la dll mscoree.dll (dans dossier Windows) qui s'en occupe.
  • Le manifeste qui indique quelles sont les assemblies nécessaires à l'exécution de ce programme.
  • Le code IL au format identique quelque soit le système d'exploitation.

Moralité, si l'on y réfléchit bien, dès que l'on souhaite créer un programme pour une plateforme .NET, il suffit d'avoir un générateur (autrement nommé, à tors, compilateur) qui, à partir du code écrit dans votre langage (VB .NET, C#, etc.), génère cet exécutable. Son rôle est donc d'écrire dans votre exe :

  • Le PE Header,
  • Le manifeste,
  • Le code IL,

Les "compilateurs" livrés avec le MS .NET Framework (pour Win32)

Ce "compilateur", vous l'avez si vous avez installé le .NET Framework sur votre ordinateur. Pour Visual Basic, il se nomme vbc.exe, pour C#, csc.exe, etc. Dans tout exécutable, il va écrire les informations suivantes :

  • Dans le PE Header, c'est la dll mscoree.dll qui prends en charge l'exécution du programme,
  • Dans le manifeste, il indique quelles sont les assemblies nécessaires à l'exécution du programme,
  • Dans la partie code IL, le code IL normalisé par la CLI.

Il faut remarquer que le code IL qu'il va créer est le même pour tout OS, ce qui signifie que pour Pocket PC ou pour Win32, c'est la même chose.

Le Compact Framework

Quand vous installez le Compact Framework sur votre Pocket PC, vous ne faites qu'installer un VES (Virtual Execution Engine pour .NET) sur votre machine (Microsoft pour son .NET Framework a appelé son VES CLR pour Common Language Runtime). Cela signifie que quand le système d'exploitation devra exécuter une application .NET, il lira le PE Header, verra que c'est son VES qui doit le prendre en charge, lancera le VES qui exécutera votre programme.

Hors pour Pocket PC comme pour Win32 (et c'est là l'astuce), il verra que c'est la dll mscoree.dll (située dans le répertoire Windows de votre Pocket PC et de votre Win32) qui s'en charge.

Moralité, la partie PE Header comme la partie code IL est la même (physiquement) pour un OS type Win32 que pour un OS pour Pocket PC. La seule chose qui change, ce sont les références, écrites dans le manifeste, vers les assemblies :

  • une application win32 aura besoin de l'assembly mscorlib (2 Mo) prévue pour Win32,
  • une application Pocket PC aura besoin de l'assembly mscorlib (380 Ko) prévue pour Pocket PC.

Il suffit donc qu'au moment de la "compilation" de votre code pour Pocket PC, vous indiquiez que vous voulez utiliser la dll mscorlib pour Pocket PC.

Application concrète

C'est bien beau tout ce discours mais comment t'set-y kon fait ?

Ouvrez donc votre éditeur de code préféré, c'est-à-dire le bloc-notes et saisissez le code suivant :

Imports System.Windows.Forms

Public Class frmMain
     Inherits System.Windows.Forms.Form 

     Public Shared Sub Main() 
          Application.Run(New frmMain) 
     End Sub 

     Public Sub New()
          MyBase.New() 
          Me.Text = "c2iHelloWorld" 
     End Sub 

     Private Sub frmMain_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Click 
          Me.Close 
     End Sub
End Class

  • La méthode partagée Main, point d'entrée de l'application, créée une instance de la classe frmMain.
  • Le constructeur New de la classe frmMain créé une instance d'une WinForm (grâce à MyBase.New()) et affecte le titre "c2iHelloWorld" à la fenêtre qui apparaitra.
  • Quand on clique sur la fenêtre (frmMain_Click), on ferme la fenêtre donc l'applicatio.

On a donc maintenant un fichier .vb (que j'ai appelé c2iHS.vb) prêt : on n'a plus qu'à le "compiler".

Pour cela, on va donc créer un fichier .bat avec une ligne de commande. Si l'on veut "compiler" cette application pour Win32, il suffit d'écrire :vbc.exe c2iHW.vb /r:Microsoft.VisualBasic.dll,System.Windows.Forms.dll,System.dll

On indique ainsi que l'exe que l'on crée pour pouvoir fonctionner à besoin de Microsoft.VisualBasic.dll, de System.Windows.Forms.dll et de System.dll.

Que fait le "compilateur" en réalité : il génère le PE Header, le code IL et le manifeste. Dans le manifeste, il indique que pour pouvoir fonctionner correctement, cet exécutable à besoin des dll Microsoft.VisualBasic.dll, System.Windows.Forms.dll et System.dll.

La question primordiale qu'il faut se poser c'est : quelles dll indique-t'il ?

Prenons l'exemple de la référence vers System.dll. Il regarde dans un premier temps si System.dll est présent dans le même répertoire ou est exécuté le .bat. Si il ne la trouve pas, il regarde dans le Global Assembly Cache (GAC) si elle est présente. Si les deux recherches échouent, le "compilateur" refuse la compilation. Sinon, il inscrit dans le manifeste tout un tas d'information (que je ne décrirais pas ici), précisant que c'est cette dll là dont il a besoin et pas une autre.

Quand on exécute donc notre fichier .bat, il s'aperçoit que toutes les dll sont dans le GAC. Il compile donc avec ces informations et si vous double-cliquez sur le .exe, la fenêtre apparaitra.

Maintenant, ce que l'on veut, c'est crée la même application mais pour Pocket PC. Je me répète mais la seule différence, c'est que les dll référencées sont différentes, ce sont celles spécifiquement prévues pour le Pocket PC qui nous intéresse.

Moralité, nous allons copier ces dll dans le dossier ou sera compilé notre exécutable. On va donc dans le dossier du Compact Framework contenant ces dll, on les sélectionne, on les copie, on retourne dans notre dossier contenant le fichier source .vb et le fichier batch .bat, on colle les fichiers.

Moralité, quand on "compilera", le compilateur verra tout d'abord dans le répertoire ces dll qu'il référencera dans le manifeste : il n'ira pas les chercher dans le GAC.

Dans notre répertoire, on doit donc avoir les fichiers suivants :

  • compile.bat
  • c2iHS.vb
  • mscorlib.dll
  • system.windows.forms.dll
  • system.dll
  • Microsoft.VisualBasic.dll

Les 4 derniers fichiers sont ceux présents dans le dossier CompactFrameworkSDK\v1.0.5000\Windows CE, c'est-à-dire ceux qui seront (ou sont) installés sur votre Pocket PC.

Exécutez votre fichier batch (.bat) et vous obtiendrez alors le fichier c2iHS.exe. Si, sous Win32, vous essayez de l'exécuter, il refusera (normal, ces dll ne sont pas prévues pour Win32).

Copiez alors votre exécutable (et uniquement l'exécutable) sur votre Pocket PC et lancez tranquillement votre application "splendide" avec votre stylet : It works !

Conclusion

Pour créer une application pour Pocket PC avec le bloc-notes, il faut tout d'abord que le MS .NET Framework soit installé sur votre ordinateur pour pouvoir utiliser le compliteur vbc.exe ou csc.exe.

Il vous faut ensuite le Compact Framework SDK. J'avoue ne pas connaitre l'adresse URL ou se le procurer (je l'ai grâce à Visual Studio .NET 2003) mais je pense que vous le trouverez sur le site de Microsoft.

Ecrivez votre code source avec le bloc-notes.

Copiez les dll du Compact Framework nécessaires au fonctionnement de votre application dans le même répertoire que votre code source.

Créez, dans ce même répertoire un fichier batch appelant le "compilateur" de votre choix (vbc, csc, etc.) avec comme argument des références vers les dll.

Copiez l'exécutable sur votre Pocket PC et ... profitez !

NB : Rotor

Dans l'une des démos des DevDays 2003, il est présenté une application fonctionnant sous WinXP, FreeBSD, MacOS. Un simple copier-coller permet le déploiement de l'application.

Le principe est simple et s'appuie sur le projet Rotor. Ce dernier permet de créer un .NET Framework pour les trois systèmes d'exploitation. Ils ont donc tous les trois le même .NET Framework, donc les mêmes dll. Moralité, le contenu de leur manifeste peut être le même donc le même fichier .exe (ou .dll) peut être exécuté sur les 3 plateformes.

Ce qu'il faut retenir c'est que pour qu'un même exécutable puisse être exécuté sur différentes plateformes, il faut impérativement que toutes les informations dans le manifeste soient indentiques, donc que les assemblies référencées soient identiques.

Le bloc-notes, c'est cool mais...

Promis, nous verrons dans un prochain article comment développer pour le Compact Framework avec des outils, gratuits, mais plus évolués que le bloc-notes.

 

Richard Clark

 
   

Copyright 2001-2004 - Tous droits réservés
Toutes les autres marques et produits présents dans ces pages sont la propriété exclusive de leurs sociétés respectives.