Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
dll et dépendances
Bonjour,
J'embarque des dll oracle dans mon appli en c#.
Dans cette même appli, je voudrais utiliser dans une autre partie le package oracle installé sur le PC et ignorer les dll que j'ai embarqué.
Comment faire? Y a t'il une commande qui permettrait de faire cela?
Merci !
bonsoir,
Il faut utiliser System.Reflection pour charger/referencer ou decharger des assembly.....
Sur le Net tapoter :
unload referenced assembly c#
a+
Bonjour,
De quel type de DLL parles-tu ? S'agit il de DLL natives ou managées (assembly) ? Car les deux ne se chargent de la même manière.Envoyé par lucieseb
Cela devrait être possible. Mais ce ne sera pas trivial. Il nous en faut plus sur le contexte général, notamment l'aspect native/managé des DLLs à charger, ainsi que la manière dont elles sont chargées actuellement.
Attention, on ne peut pas décharger spécifiquement un assembly. La seule chose qui puisse être faite, c'est de décharger le AppDomain dans lequel a été chargé l'assembly (mais cela décharge l'ensemble des assemblys de ce AppDomain).
Bonjour,
J'embarque ces dll : oci.dll, Oracle.DataAccess.dll, oramts.dll, oramts11.dll, orannzsbb11.dll, oraociei11.dll et OraOps11w.dll
Le problème ne vient pas tant du fait de les embarquer, ça fonctionne très bien.
Mais à partir du moment où j'appelle depuis mon appli un autre module (qui n'embarque pas ces dll), il a l'air de lui "passer" ces dll et la connexion passe par ces dll.
J'aurai voulu dans mon autre module, faire le "ménage" si c'est possible car à ce moment ça ne fonctionne plus.
Merci pour vos réponses très précieuses !
Alors, histoire de simplifier les choses, il y a à la fois des DLLs natives et managées !
Comment est appelé ce module ? S'agit-il d'un exécutable lancé par l'application ? D'un plugin ? Il nous faut des informations sur la manière dont l'application est architecturée.
oui merci francois je suis au fait de tout ce qui attrait au referencement de dll en general :
https://bitbucket.org/3dotdev/dotnet...bly/?at=master
a+
Le module peut être un exe ou un bat (j'ai même essayé en java) qui est lancé par l'application.
Je vais étudier la question du référencement et le déchargement des assembly du AppDomain, c'est peut être LA solution.
Merci
Ok, très intéressant à savoir !
Je ne pense pas que cela soit la solution malheureusement. Voici pourquoi. A priori, ton programme C# charge un assembly, qui doit lui-même interagir avec des DLLs natives. Et donc les charge à partir du répertoire de l'application.
Ton programme peut également lancer un module (disons un exe, mais le problème serait le même un .bat). Lorsque le module est lancé, il charge les DLL nécessaires. Lorsqu'un processus charge des DLLs, il regarde dans les emplacements suivants, et dans cet ordre :
- la mémoire
- le dossier de l'application
- le dossier système
- le PATH
- le dossier courant
Du coup, on peut voir en 1 que la recherche se fait d'abord depuis la mémoire.
Ce qui explique le comportement que tu sembles avoir. Avec un link statique des DLLs (ce qui semble le cas ici), je crois (mais à confirmer) qu'il n'est pas possible d'avoir deux versions différentes d'une même DLL. Dans ce cas, il faut se tourner vers un link dynamique. Mais c'est plus lourd à mettre en oeuvre...
Je n'en doute pas. Cette précision était simplement pour notre lectorat
Merci pour ces précisions, je ne connaissais pas l'ordre de charge, maintenant je comprends mieux le résultat que j'ai.
Je vais tenter le lien dynamique avec Assembly.LoadFile(@"chemindll");
Mais le problème ne sera t'il pas le même puisque le lancement de l'autre exe viendra après le chargement dynamique des dll?
En plus l'appel à l'exe, par exemple, va se faire plusieurs fois dans l'appli...
L'autre solution aurait été de mettre un service à l'écoute sur le PC, comme ça l'exe sera lancé avant l'appli, mais je n'aime pas trop l'idée
L'appel à Assembly.LoadFile(@"...\oci.dll") donne l'erreur "Le module était censé contenir un manifeste de l'assembly. (Exception de HRESULT : 0x80131018)"
Pour faire simple, il existe deux types de DLLs : les DLLs natives et les DLLs managées. Assembly.LoadFile ne peut charger que des DLLs managées. Il y a donc de forte chance que oci.dll soit une DLL native. D'où l'erreur.
bonjour,
Il y a ici un peu d'info concernant la decoration des methodes pinvoke :
https://stackoverflow.com/questions/...ath-at-runtime
Et eventuellement ici une solution pour appeler dynamiquement une dll native (notion de chargement + dechargement) :
https://blogs.msdn.microsoft.com/jon...ll-from-net-c/
https://stackoverflow.com/questions/...ative-dll-file
https://stackoverflow.com/questions/...-unmanaged-dll
MSDN :
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
Bonne lecture.
Bonjour,
Merci pour la lecture !
Il y a peut être plus simple.
En fait mon problème est de pouvoir gérer plusieurs configurations différentes (c'est à dire des PC avec des clients oracles de version différente) sans avoir à compiler une version d'appli différente à chaque fois.
Est ce que vous croyez qu'il y a plus simple?
Merci encore !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager