Les librairies (.dll)

Qu'est-ce qu'un fichier .dll?

L'abréviation dll signifie Dynamic Link Library. C'est un concept très répandu dans le monde Microsoft qui consiste à créer des librairies de classes (ou de fonctions dans le cas d'un langage non objet) implémentant des fonctionnalités particulières. Une librairie n'est pas exécutable. Quelqu'un peut ensuite lier la librairie à son programme et utiliser ses fonctionnalités, sans nécessairement avoir accès à son code. L'exécutable ainsi créé ne contient pas la librairie mais contient un lien sur celle-ci, qui doit donc être accessible sur l'ordinateur qui l'exécute pour que tout fonctionne. On placera parfois la librairie dans le même répertoire que l'exécutable, mais plus souvent on retrouvera les librairies dans le répertoire C:\Windows ou C:\Windows\System32.

Il arrive fréquemment qu'une entreprise fournisse vende ses produits sous forme de .dll. Ses clients utiliseront le .dll pour implémenter certaines fonctionnalités mais ne pourront pas voir le code qu'elle contient.

Créer sa propre librairie

Créer une librairie, c'est fort simple. Lorsqu'on crée un nouveau projet dans Visual Studio, on choisit "Bibliothèque de classe" plutôt que "Application Windows" ou "Application Console".

On se retrouve dans un projet similaire à ce qu'on est habitué d'utiliser, à la différence qu'il n'y a pas de section "main". On y placera là les définitions de classe que l'on veut, réparties en différents fichiers et/ou espaces de noms si on le désire.

On ne peut pas exécuter le résultat, on doit simplement le compiler. Comme pour tout programme, on choisira de le compiler en mode Release lorsqu'on sera prêt à le distribuer. Le fichier .dll sera alors placé dans le répertoire bin/Release du projet.

Reprenons l'exemple du module 7 sur les événements. On peut très bien faire une librairie Horloge qui contiendra les définitions de la classe Horloge et de la classe TimeEventArgs, puis la compiler.

On a soudainement un problème: le compilateur ne trouve plus System.Windows.Forms.Application.DoEvents, qui nous permettait de laisser l'ordinateur traiter des événements extérieurs entre deux vérifications d'heures. Pourquoi? Simplement parce que notre projet actuel n'a pas de lien vers la librairie System.Windows.Forms, lien qui est automatiquement créé pour nous lorsque l'on fait un formulaire Windows - mais pas lorsqu'on fait une librairie!

Nous n'avons qu'à recréer ce lien, puisqu'on a besoin de la fonction. Il suffit alors d'aller dans l'explorateur de solution pour ouvrir la branche Références. En cliquant avec le bouton de droite sur Références, on peut en ajouter une nouvelle. On trouve dans la liste de librairies .NET System.Windows.Forms et voilà! Une fois la référence ajoutée, on s'assure que nos classes sont déclarées comme publiques (ce n'était pas nécessaire avant puisque le code qui les utilisait était dans le même projet et dans le même espace de nom). Ensuite, notre librairie compile correctement et le .dll est créé.

Remarquez qu'alors ce .dll a besoin du fichier System.Windows.Forms.dll pour fonctionner. Ce n'est pas une solution parfaite, puisqu'on voulait au départ que notre Horloge soit indépendante de toute interface... Mais si on enlève l'appel à la fonction (et donc la référence), notre Horloge gèle notre application. Il existe bien entendu une solution à ce problème, qu'on verra dans un cours futur.

Utiliser une librairie

Utiliser une librairie est aussi simple que ce qu'on vient de faire pour utiliser System.Windows.Forms. On peut donc modifier notre application Windows pour qu'elle utilise notre librairie Horloge plutôt que d'utiliser un fichier .cs interne.

Il suffit d'ajouter un lien vers notre fichier .dll (à peu près de la même façon que ce qu'on a fait ci-haut, excepté qu'on va aller dans l'onglet "Fichier" plutôt que l'onglet ".NET" pour trouver notre dll.

Une fois que la référence est faite, on devra tout de même modifier un peu notre code afin de respecter la nomenclature Librairie.Classe.Méthode - maintenant que les classes Horloge et TimeEventArgs ne sont plus dans notre espace de noms, on devra explicitement utiliser Horloge.Horloge et Horloge.TimeEventArgs. Tout le reste fonctionnera normalement.

 

Etienne Forest, 20 novembre 2007