Deux exécutable, une DLL: sera-t-elle chargée une seule fois?

Bonjour à tous,

Le titre est explicite, je m'interroge sur comment le chargement d'une même DLL entre deux exécutable est géré sous .NET.

Concrètement, j'ai deux exécutable dans un répertoire AppA.exe et AppB.exe. Ces deux exécutable utilisent une librairie gourmande quant à l'utilisation de la mémorie: Lib.dll. Étant donné que AppA et AppB fonctionnent dans un environement limité (un PDA) l'utilisation de la mémoire doit être optimal.

Donc, ma question est: Est-ce que ladite DLL sera chargée une seule fois pour les 2 exécutables ou si elle sera chargée deux fois en mémoire (soit une fois pour chaque exécutable)?

En Win32, à moins que je me gourre, la DLL sera chargée qu'une seule fois (indépendament de sa location et de sa version) et c'est justement cela qui, selon wikipedia, a donné naissance à l'expression `DLL Hell`.

Je connais l'existance de la GAC, mais j'essais de l'évité autant que possible, étant donnée qu'elle occasionne une complexité pour le déploiement des applications qui serait facilement évitable. De plus, ladite librairie dépend sur plusieurs autres DLLs propriétaires dont je ne possède pas le code source et qui n'ont pas nécessairement de `Strong Name`.

J'ai cherché sur le web et sur le forum, mais sans succès. Donc, votre aide sera très appréciée :).

Ah de plus, si vous avez une idée sur comment je pourrais découvrir la réponse par moi-même ce sera tout autant apprécié :) Pour l'instant j'essais de créer un projet bidon avec une giga librairie et observé l'utilisation de la mémoire, mais c'est c'est pas génial :).

Je n'ai pas de réponse 100% sûre, mais a priori je dirais que, vu que tes 2 exe tournent dans 2 AppDomain différents, la DLL est chargée deux fois : une fois par AppDomain. Cela dit, il est possible que le CLR gère ce genre de cas et ne charge en fait l'assembly qu'une seule fois pour optimiser... surtout sur le compact framework où la mémoire est une contrainte importante.

Un moyen simple de le savoir serait de mesurer la mémoire utilisée quand chacune de tes applis tourne seule, et la mémoire utilisée quand elles tournent ensemble.

Sinon tu peux essayer dee poser la question sur les forums MSDN, avec un peu de chance un grand gourou te répondra ;)

Citation:

---

Envoyé par tomlev

Un moyen simple de le savoir serait de mesurer la mémoire utilisée quand chacune de tes applis tourne seule, et la mémoire utilisée quand elles tournent ensemble.

---

En fait je me demandais... si ladite librairie est chargée une seule fois, est-ce que la mémoire nécessaire au code de la librairie sera assigné au premier process ou si elle sera assignée à la "machine virtuelle" de .NET?

Citation:

---

Envoyé par scadieux

En fait je me demandais... si ladite librairie est chargée une seule fois, est-ce que la mémoire nécessaire au code de la librairie sera assigné au premier process ou si elle sera assignée à la "machine virtuelle" de .NET?

---

Le CLR n'est pas un process, donc c'est l'application elle-même qui utilise la mémoire

Je vois... merci :)

Sinon de mon côté je suis tombé sur ce lien magique:
http://blogs.msdn.com/stevenpr/archi...05/347353.aspx

J'apporte votre attention à cette section de l'article:
http://blogs.msdn.com/stevenpr/archi...x#_Toc92680339

Dans laquelle on nous explique:

Citation:

---

The file specified in the reference is loaded and its friendly name extracted. If a weakly named assembly with that friendly name has already been loaded, that assembly is considered to satisfy the reference and the assembly identified by the path-based reference is discarded. Said differently, only one assembly of a given identity may be loaded at a time.

---

Cependant ils nous indique ceci au début de la section:

Citation:

---

Path-based references are specified by calls to Assembly.LoadFrom, AppDomain.ExecuteAssembly, or Assembly.Load (when called with the codebase property set in the AssemblyName).

---

Étant donné que les assemblies ne sont pas chargé à l'aide de ces méthodes j'ai un doute quant au fait que mes assemblies sont chargée qu'une seule fois. Néanmoins c'est un pas dans la bonne direction (j'imagine...).

Sinon, pour retourner à la GAC, j'ai fini par être capable de tout signer, la librairie non-signée était en fait un sample de code fournit par Microsoft pour la localisation GPS. Alors j'ai téléchargé les sources corriger 2-3 de leur bogues et recompiler le tout en signant mon assembly. Cependant, je crois que j'ai un peut de misère avec le concept de la GAC sous Windows Mobile.

J'ai créer un fichier .gac dans lequel je réfère aux DLLs (lesquelles sont situées dans un répertoire différent de celui de l'application) que j'ai déposé dans le dossier Windows. Cependant mon application m'indique qu'elle ne réussit pas à trouver l'assembly.

Effectivement aucune fichier GAC_... n'a été créé pour ma librairie dans le dossier Windows. Donc pas étonnant que l'assembly ne soit pas trouvé...

C'est pas clair tout ce processus de GAC...

Heu ... un fichier .gac ?

Ce n'est pas gacutil qu'il faut utiliser pour enregistrer une dll dans le gac ? (pas sur vu que Windows CE et moi ...).

Salut.

L'extrait de la msdn parle (sauf erreur de ma part) du chargement d'une même librairie dans un même domain d'application. Or le lancement de deux exécutable crée 2 app domain (un par process). Dans ton cas la librairie sera bien chargée 2 fois. D'ailleurs ce comportement est normal, si la librairie n'était chargée q'une fois et partagée entre les applications, alors les données qu'elle manipule (et à plus bas niveau, la mémoire) serait partagée entre les applications. Or sauf exemple prouvant le contraire, si tu lances 2 applications utilisant une même librairie qui définie une variable statique, les deux applications peuvent faire varier cette variable de manière indépendante.

D'autre part comme le dit Smyley, le GAC n'est pas un fichier mais bien un "container" dont l'outil de manipulation est gacutil ;)

En ce qui concerne le fichier .gac, je vous redirige vers la msdn: http://msdn.microsoft.com/en-us/library/kw5x2w30.aspx.

Pour l'application domain, je ne suis pas sûr à 100%, mais ce que contient l'Application Domain n'est pas seulement les variables dynamiques et statiques?

Ce que je veux dire, c'est est-ce que l'algorithme alentour de ces variables n'est pas chargé qu'une seule fois?

Je suis pas très callé côté bas niveau, alors je dis p-e des conneries :)

Citation:

---

Envoyé par scadieux

En ce qui concerne le fichier .gac, je vous redirige vers la msdn: http://msdn.microsoft.com/en-us/library/kw5x2w30.aspx.

---

Ok autant pour ma culture :D

Citation:

---

Envoyé par scadieux

Pour l'application domain, je ne suis pas sûr à 100%, mais ce que contient l'Application Domain n'est pas seulement les variables dynamiques et statiques?

---

Non, l'app domain géré également les assemblies utilisés par les applications. C'est d'ailleur un des moyens permettant d'isoler une assembly dans lequelle on n'a pas confiance.

Ce que je veux dire, c'est est-ce que l'algorithme alentour de ces variables n'est pas chargé qu'une seule fois?

De toute façon, généralement, ce ne sont pas les algo qui prennent de la place mais bien les données stockées par les algos ;)