Problème avec une dll non chargé (ou presque)

Question

Bonjour,

J'ai un petit problème avec une dll et je ne m'en sort pas :
- A l'aide de AxImp.exe, j'ai crée les dlls AxWMPLib.dll et WMPLib.dll (basé sur wmp.dll, media player^^)
- Je les charges dynamiquement dans mon application à l'aide de Reflection.Assembly.LoadFile(le chemin)

Après ça, j'ai une fonction qui liste tout les types de la dll. A ce moment là j'ai une exception "impossible de charger le fichier ou l'assembly WMPLib, 1.0.0.0,..Etc ou l'une de ses dépendance car le fichier est introuvable."
J'ai put en déduire après quelque analyses que AxWMPLib.dll ne trouve pas WMPLib.dll (alors que je pensai au début que c'était mon application qui ne la trouvait pas).

Après une longue recherche je me suis aperçu que si je met ces 2 dll dans le dossier racine de mon application, je n'ai plus d'erreur (je précise que les 2 dll, à la base, ne sont pas dans le dossier ou sous dossier de mon application).

Alors que faire pour ne plus avoir de problème sans être obligé de copier ces 2 fichiers dans le répertoire de mon application?

Je précise également que je n'ai pas d'erreur disant qu'il n'arrive pas à charger ces 2 fichier, sous entendu qu'il arrive à les charger donc. 
Je précise également qu'en mode débug, en listant les modules à l'aide de "fenêtre commande", je m'aperçoit que l'état des symboles de ces deux dll sont "Aucun symbole n'a été chargé."

Voila, je crois que je n'ai oublié aucun détail de ce que j'ai put déjà recherché ^^

Merci d'avance du coup de main
 


Veler Software
La simplicité et la performance

cs_casy · Answer

TU n'as pas d'erreur au chargement, probablement parce que tu indique le chemin complet lors du chargement.
Tu pense que ce n'est pas ton appli qui ne trouve pas une dll mais plutot une des dll qui ne trouve pas l'autre.
Lorsque les 2 dll sont dans le même dossier que l'appli, il n'y a pas de problème. 

On peut tenter une première déduction. Ton appli sait trouver les dll puisque tu lui indique le chemin. Par contre, une des dll doit certainement avoir besoin de l'autre, mais comme elle, elle n'a pas de chemin ou la chercher, elle la cherche dans les chemins de recherche par défaut, à savoir, dans l'ordre de recherche :
- le chemin courant
- le chemin du binaire executable (ici, la dll)
- Le dossier "Windows" du système, généralement C:\Windows
- le dossier "Système" du système, généralement C:\Windows\System32
- enfin, les différents chemins indiqués dans la variable d'environnement PATH

Déjà peut-être peux-tu essayer de mettre les 2 dll dans le même dossier

[i][b]---- Sevyc64  (alias Casy) ----
[hr]# LE PARTAGE EST NOTRE FORCE #/b/i

cs_veler · Answer

Ca résume très bien ce que j'ai dit. Je viens d'essayer, si je les met par exemple dans le dossier Windows, il les trouves aussi.
Une chose que j'ai oublié de précisé justement, les 2 dll sont tout les 2 dans le même dossier.
En fait j'ai par exemple mon application dans ProgramFiles, et ces 2 dll dans un dossier de Mes Documents, bien entendu il faut s'attendre à ce que se dossier change selon les ordinateurs, lol


Veler Software
La simplicité et la performance

cs_veler · Answer

Salut,

D'abord, petite rectification, dans le dossier Windows, marche pas, dans System32, ça fonctionne ^^

Après encore des recherches, j'ai put lire qu'il fallait absolument que les 2 dll soit dans le répertoire de l'application, chose qui m'étonne fortement quand même, je ne me fi pas beaucoup à cette source 

Peut-être faut-il indiquer ou se trouve la dll dans le registre, mais ou dois-je faire ça dans le registre? De plus, la dll peut changer d'emplacement n'importe une fois l'application quitté. 

Au pire des cas je fait un copier/coller des dll dans le dossier de mon programme, via mon application bien sûre, mais bon ce n'est pas très pratique et ça peut provoquer des bugs assez facilement.

si quelqu'un a une idée ^^
@+


Veler Software
La simplicité et la performance

cs_veler · Answer

personne? 


Veler Software
La simplicité et la performance

cs_veler · Answer

C'est encore moi !

Bon, je viens d'essayer de donner le dossier dans lequel se trouve les 2 dll à la variable d'environnement PATH, fonctionne pas plus 

Aller, bientôt une semaine que je suis sur le problème --"


Veler Software
La simplicité et la performance

Mayzz · Answer

Tiens salut veler ^^

Bon pour ton problème :

1\Laisse ton assembly Ax .Net dans le dossier de ton appli.
2\Copie ta DLL ActiveX dans le système: WMPLib.dll
3\Exécute 'regsvr32.exe' en passant le nom de ta DLL en param : regsvr32 wmplib.dll
4\Ton Ax .Net doit maintenant trouver ton ActiveX automatiquement.

ATTENTION, ce n'est pas tout, tu dois aussi mettre ton application en x86 exclusivement (dans les options de compile) pour éviter les soucis avec les système x64. (Dans ce cas bien mettre copier l'ActiveX dans le WOW et pas dans le système courrant). Ton appli ne tournera qu'en 32bits, mais t'as pas vraiment le choix, si tu dois obligatoirement tourner en AnyCPU alors dis le moi je te donnerais la marche à suivre si je ne me trompe pas, les Ax sont la pour faire la trad mais à voir...

Encore une chose, il y a un bug avec certains Ax .Net, lors ce que tu crée dynamiquement un contrôle, il doit avoir un support tel, une form ou un control, tu dois initialiser celui-ci comme suit :

'Déclaration :
Private WithEvents Player As New AxWMPlayer' AxWMPLayer à remplacer par le nom de l'assembly de ton Ax, si c'est pas ça..

'Initialisation:
Me.SuspendLayout(True)
CType(Player, System.ComponentModel.ISupportInitialize).BeginInit()
Me.Controls.Add(Player)
CType(Player, System.ComponentModel.ISupportInitialize).EndInit()
Me.ResumeLayout

En théorie après plus de soucis tous devrait fonctionner (je dis bien en téhorie).

Après encore des recherches, j'ai put lire qu'il fallait absolument que les 2 dll soit dans le répertoire de l'application

Faux, l'assembly de l'Ax .Net doit rester dans le dossier de ton appli et l'ActiveX dans le système du client faisant partie intégrante du système et non de ton appli (c'était tout le problème lors ce que l'on développait des ActiveX avec vb6, l'enregistrement du contrôle dans le registre ne permettait pas la mobilité du fichier contrairement au assembly .Net).


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_veler · Answer

Salut,

Merci beaucoup pour ta réponse.

J'ai un problème pour regsvr32, il me retourne "Le module WMPLib.dll a été chargé, mais le point d'entré DLLRegisterSever est introuvable. Vérifiez que WMPLib.dll est un fichier DLL ou OCX valide, puis réessayez." 

Etrange qu'il dise ça vu que cette dll est parfaitement lu par mon application quand je la met dans le dossier où se trouve mon exe 

Je viens que chercher une solution sur internet à ce problème là, euuuuh, il n'y en a pas vraiment >.<


Veler Software
La simplicité et la performance

Mayzz · Answer

Heu... ouais en effet, c'est pas normal, donc d'après toi WMPLib.dll serait une API et non un Lib ActiveX ???

Bon, ca y'est ça m'intrigue, je prend 5 minutes pour tester ca !

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

Mayzz · Answer

Mouais...

Je suis sous vista x64, j'ai regardé dans mon Systeme et dans mon WOW, pas de trace de WPMLib.dll, sur le net aussi, je ne trouve que l'ax en DL, et pas la DLL. De quelle version de Winows media s'agit-il ?

Pour le reste, je dispose de la version 11 de media player (livré par défaut avec Vista), et j'ai WMP.dll, qui s'enregistre dans le système via DLLRegisterSever sans problèmes, tu peux peut être tester avec cette version ?



Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_veler · Answer

Salut,

Et bien je reprend un peu :
- A la base j'ai WMP.dll, qui est dans system32 (j'ai Seven 32bit)
- Avec AxImp.exe, j'ai put créé les dlls AxWMPLib.dll (.Net), et WMPLib.dll (???).
- J'ai également la version par défaut de Windows Média (je crois que c'est la 12 sous win 7).
- J'ai testé également la méthode que j'ai utilisé avec d'autres dll (notamment flash, quicktime, adobe reader), et j'ai exactement les mêmes problèmes.

Je ne sais pas si ça peux aidé mais j'ai essayé le démarche (resvr32) avec RegAsm, bon, ça s'inscrit correctement, mais ça ne résous en rien le problème XD


Veler Software
La simplicité et la performance

Mayzz · Answer

Et lors ce que tu dessine le contrôle via l'Ax en dans l'EDI de VS comment ca se passe ?

De mon coté : (via l'EDI VS), j'ajoute le COM dans ma toolbox, dans les refs de mon projet j'ai donc :

../Interop.WMPLib.dll
../Axinterop.WMPLib.dll

Je suppose donc que j'ai la même chose que toi en gros... Au début je pensait que l'interop était en fait, une copie local de l'ocx original, afin que l'Ax puisse le retrouver dans le répertoire mais c'est faux, en faisant un test, j'ai une erreur 'Class Not reg', j'en déduit donc, que pour fonctioner, les deux assembly générés par notre ami aximp, doivent se trouver dans le répertoire du projet, et que l'activeX originale quant à lui, doit être présent et enregistré dans le registre via regsvr32.

Donc:
WMP.dll ==> Sytem32 + regsvr32
WMPLib.dll => répertoire projet + référencé par le projet
AxWMPLib.dll => répertoire projet + référencé par le projet

Si cela ne fonctionne toujours pas, le problème ne vient pas de la. 

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_veler · Answer

Salut,

Et bien en fait j'ai le regret de t'annoncer que si j'ai ce problème, c'est parce que pour mon logiciel ( ), je créer une fonction permettant à l'utilisateur d'ajouter des références COM à leur projet tout comme VS le fait justement 

Je rappel que le problème de base est que AxWMPLib.dll ne trouve pas WMPLib.dll alors que SoftwareZator l'a chargé en mémoire ^^


Veler Software
La simplicité et la performance

Mayzz · Answer

Arf, c'est bien ce qui me semblai, avec tout ca, j'en ai oublier le sujet principale, qui est que tu ne souhaite pas avoir ces assemblys dans le répertoire de ton projet... J'ai donc relu ton sujet avec plus d'attention.

C'est donc que lors ce que tu charge AxWMPLib.dll, celle ci est instancié par ton application, et qu'au démarrage, elle recherche WMPLib.dll dans le répertoire courrant (pas celui ou elle est sensé se trouvé, mais celui ou ton prog est exécuté étant donnée qu'une assembly se trouve généralement dans le répertoire de de l'exécutable, je pense que ces messieurs de ms n'on tout simplement pas pensé à ca). La par contre je ne vois pas... Désolé. 

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

Mayzz · Answer

Pourquoi ne copirais-tu pas les assembly temporairement dans le répertoire de SZ le temps que l'utilisateur est dans l'EDI, puis tu copie les fichiers dans le BIN du projet SZ généré lors de la compile ?

En quoi ca pose problème ? C'est un souci de 'propreté' ?

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

cs_veler · Answer

Oui, c'est ça, un problème de propreté, je m'explique :

le logiciel est multi-instanciable, on peut lancer plusieurs instances de celui-ci.

Premier problème : je ne peux décharger les dll car elles sont simplement chargé via assembly.load et on AppDomain (pour différentes raisons, je ne vais pas m'attarder là dessus). Donc impossible de supprimer les dlls, sauf au démarrage d'une nouvelle instance en faisant le tri.

Second problème : c'est bien beau mais si je lance une nouvelle instance et que l'une de ces dll à supprimé est utilisé par une autre instance actuellement en cour, et bien ça risque de poser quelques problèmes si tu vois ce que je veux dire ;)

Mais je ne baisse pas les bras, après tout, VS y arrive non? et il a été fait en C#, donc il y a forcément un moyen ^^


Veler Software
La simplicité et la performance

cs_veler · Answer

Salut,

Petite remarque :
Je viens de me dire "tiens, et si j'essayai d'importer les dlls que j'ai créé dans VS!?"
J'ai créé un nouveau projet et ai référencé ces 2 dlls... et bien tout fonctionne correctement  On pourrai peu-être penser que le problème vient du chargement de mes dll? Enfin ce n'est qu'une idée.

Voici, par hasard =P, la façon dont je charge les références des projets créé par mon logiciel :

J'ai une collection, et tout simplement je fait MaCollection.Add( New VelerSoftware.SZVB.Projet.Reference(Reflection.Assembly.LoadFile(XmlRead.GetAttribute("value")) )

Petite remarque (on ne sait jamais, lol), la Class VelerSoftware.SZVB.Projet.Reference se trouve dans une bibliothèque de ma création, pas directement dans l'application, je ne sais pas si se détail peut aider mais bon :)

Voili voila XD

Encore merci de votre aide


Veler Software
La simplicité et la performance

Mayzz · Answer

Petite remarque : 
Je viens de me dire "tiens, et si j'essayai d'importer les dlls que j'ai créé dans VS!?" 
J'ai créé un nouveau projet et ai référencé ces 2 dlls... et bien tout fonctionne correctement  On pourrai peu-être penser que le problème vient du chargement de mes dll? Enfin ce n'est qu'une idée. 

Tu parles d'assmbly VS ? De Lib créés avec VS directement ? Dans ce cas la oui ca fonctionne et, encore heureux !

Le problème, vient des activeX de vb6, lors ce que tu choisis un compo COM, pour ta toolbox, VS fait appel à aximp pour générer un composant de compatibilité .Net, qui n'est rien d'autre qu'un assembly .Net faisant le lien entre l'activeX et VS, VS, n'importe pas directement le contrôle activex au sein du projet, du coup le schéma ressemble à cela :

Projet <=> Ax => Dll ?? => ActiveX système.

Le souci à mon avis c'est que l'ax est instancié par SZ, donc le répertoire courrant de l'ax (peut importe ou il soit situé physiquement) est en fait le réperoire physique de SZ, car c'est SZ qui lance l'instance, du coup l'ax, je pense, recherche la DLL dans le répertoire courrant (et non à son emplacement physique) et ne la trouve pas.

Petite remarque (on ne sait jamais, lol), la Class VelerSoftware.SZVB.Projet.Reference se trouve dans une bibliothèque de ma création, pas directement dans l'application, je ne sais pas si se détail peut aider mais bon :) 

Si ce que je pense est vrai, tu peux l'expérimenter en créant une classe dans une assembly différente qui servira à charger les assembly d'ax dans ta collection, cette assembly devra se trouver dans le répertoire 'COM' de SZ (répertoire ou tu met tes Ax temporairement). Si mes dires sont exactes cela ne changera rien au problème mais si je me trompe ca te fera avancer d'un poil.

++ Mayzz

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

Problème avec une dll non chargé (ou presque)

17 réponses

Votre réponse

Discussions similaires