Discussion :

[sergio_bzh]

Bonjour,
mon titre n'est peut-être pas très clair !

Je compile donc une appli VB.Net ou j'utilise entre autre la référence ADO (2.8).

Quand je récupère l'exe seul de bin/release et que je le mets par exemple dans C:\ , il ne fonctionne pas. Normal, il veut la DLL Interop.ADODB qui est dans le même répertoire bin/release.
Mais je ne comprends pas pourquoi il copie la DLL Interop.ADODB dans bin/release puisque je vais la chercher sur le même poste et qu'elle est référencée dans VB.Net (et sinon je ne pourrais pas aller la chercher !).

Dans les proporités du projet, il y a bien une option "Copie locale" = true/false mais de toutes façons si je met à false ça ne compile plus. Et évidemment si je mets à true, il faut l'embarquer à l'exe.
De plus, la DLL est copiée en local au moment du "add reference"

bref, comment faire pour qu'il aille référencer la DLL installée sous Windows ?

Merci.
Sergio

[Pol63]

la dll est elle forcément quelquepart quand tu deploieras ton projet ?

l'utilité du framework c'est d'essayer d'utiliser que des objets du framework pour éviter ce genre de problemes
ado.net t'allait pas ?

il y a une option j'crois dans les propriétés du projet pour dire des dossiers ou chercher les dll si elles ne sont pas trouvés à coté de l'exe

[smyley]

je ne pense pas que "Interop.ADODB" soit disponible par défaut sur Windows
d'après ce que j'ai compris tu as référencé un objet COM. Or il s'agit d'une lib native et il faut que tu l'utilise à partir de ton programme managé. Visual Studio génère donc une dll "Interop" qui sera le pond entre la lib COM et ton appli. Cette lib éttant générée, elle doit être embarquée car elle n'existe pas par défaut sur l'OS de destination. De plus, en soit cette dll "Interop" ne contient aucune fonction/commande d'ADO car elle ne sert que de passerelle, la dll originale devant tout de même être enregistrée dans COM ( et là, peut être qu'elle est par défaut dans Windows ... )

[sergio_bzh]

Merci pour les réponses. smiley, je pense que c'est ce que tu dis.
Et j'ai eu qqs infos supplémentaires :

Pour être plus clair, je vais redécrire ce que j'ai fait :

- Pour utiliser ADODB, je fais "add reference" sur ADO 2.8 et je vais donc chercher le fichier suivant :
"C:\Program Files\Common Files\System\ado\msado15.dll"
- sans rien me demander, il me copie en local dans "Debug" et "Release" un fichier "Interop.ADODB.dll"
Si ensuite je met "copie local = false" pour cette référence ADO 2.8, il me fait une erreur d'assembly me disant que , à priori, ma DLL d'origine (masado15.dll) devrait être "strong signed". Tout est pourtant du Microsoft "genuine" !

Je vais donc embarquer les DLL avec l'exe mais ça reste bien compliqué : à la base il y a tout ce qu'il faut sur le poste (la DLL ADO 2.8, le framework .net 2.0) mais ça ne suffit pas, il faut quand même qu'il ponde des DLLs intermédiaires ...

[smyley]

Je vais donc embarquer les DLL avec l'exe mais ça reste bien compliqué : à la base il y a tout ce qu'il faut sur le poste (la DLL ADO 2.8, le framework .net 2.0) mais ça ne suffit pas, il faut quand même qu'il ponde des DLLs intermédiaires ...

Tu aurai préféré avoir à coder toi même un wrapper COM -> .NET ?

[sergio_bzh]

Tu aurai préféré avoir à coder toi même un wrapper COM -> .NET ?

ben c'est du code repris de VB6 et en VB6 .... je livrais un fichier exe c'est tout