L'assembly privé et les dépendances DLL transitives?

Question

OK, j'ai donc réussi à mettre mon Private Assembly pour mes plugins de mon exécutable, comme described here: _{(Ceci est juste un exemple, mon cas d'utilisation est techniquement identique, mais pas pour les plug-ins en tant que tels.)}

• Executable utilise manifeste d'application pour déclarer dependentAssembly sur plugins Assemblée
• plugins sous-répertoire contient plugins.manifest
• plugins.manifest déclare assemblyIdentity avec files liste la DLL de plug-in (s) (par exemple, easyplug1.dll et xplug2.dll)

Ce que je ne comprends pas tout à fait, et nous avons pas encore trouvé une explication directe, est Qu'en est-DLLs que les DLL dans l'assemblée privée dépend de? Où devraient-ils être localisés, comment sont-ils trouvés?

Exemple: Le xplug2.dll, qui est la 3ème partie elle-même a besoin de la 3ème partie dll xbase.dll. Naturellement, xbase.dll est simplement déployé dans le répertoire plugins. Est-ce assez? L'assembly privé doit-il répertorier les DLL utilisées uniquement de manière transitoire par le module (exécutable) déclarant sa dépendance sur l'assembly plugins?

---

réponse partielle à ce jour par tâtonnement:

(A) Il semble tous DLLs, aussi ceux qui ne sont utilisés d'autres DLL « plug-in » doit figurer dans l'Assemblée privée manifeste - c'est-à-dire qu'il faut essentiellement lister tous les fichiers DLL dans le répertoire d'assemblage plugins. (A.1) Toute DLL non répertoriée ne sera pas trouvée dans le répertoire, même si elle est référencée à partir d'une DLL dans le même sous-répertoire.

(A.2) Je suppose ce dû à toutes les machines de chargement de DLL en utilisant le (uniquement) sur mesure Activation Context de l'exécutable, et si la DLL ne s'y trouve pas, il semble chercher à l'intérieur le répertoire exécutable.

(A.3) J'essayé de regarder la chaîne de dépendance avec the latest version de Dependency Walker (2.2.10011), mais il semble qu'il ne peut pas gérer ce scénario transitif à tous: les dépendances primaires sont correctement sont indiqués, mais transitive les dépendances secondaires ne sont pas résolues à partir du manifeste, mais par rapport au répertoire de base.(On peut dire qu'elle suit plain LoadLibrary semantics pour the transient ones.)

---

mise en page du fichier:

...\base\app.exe 
    // - contains Application Manifest declaring dependency on `plugins` 
    // - Loads xplug2.dll 

...\base\plugins\xplug2.dll 
    // - Loads xbase.dll (which is only used by xplug2.dll internally) 

...\base\plugins\xbase.dll 

...\base\plugins\plugins.manifest 
    // - lists xplug2.dll (for sure) 
    // - *seems* to need to list also xbase.dll 

---

Answer 1

La réponse est simple, tout dll "brutes" qui ne font pas partie d'un ensemble, seront recherchées utiliser le contexte d'activation des applications et/ou les règles de recherche dll par défaut. Et le chemin de recherche dll inclut le dossier de l'application, mais pas tous les dossiers dans lesquels dll ont été trouvés (c'est-à-dire qu'une DLL ne peut jamais s'attendre à charger une autre DLL qui est accessoirement dans le même dossier). Donc, par exemple, si un DLL de votre assembly nécessitait openssl.dll, alors il chercherait d'abord dans le dossier de l'application.exe, PAS votre dossier d'assemblage privé, sauf si vous avez explicitement ajouté explicitement openssl à votre assembly privé.

la réponse est d'ajouter explicitement openssl.dll à l'assemblée privée (ce qui contribue d'ailleurs de protéger l'intégrité de l'application si un dll différent - dans un autre assemblage - nécessitent une version différente de openssl.dll)

Dans votre cas, vous pourriez avoir deux assemblys privés différents, chacun utilisant une version privée de xbase.dll - où les deux xbase.dll différents pourraient être tout à fait incompatibles.