J'ai créé une dll sous Visual Studio 6.0 que j'arrive à utiliser en local
aussi bien avec une application VB qu'avec Access 2003.
Cependant je souhaite déployer cette bibliothèque sur un ensemble de postes
clients. Le reste des postes ne dispose pas d'un environnement de
développement mais uniquement du runtime.
A l'execution des applications, l'erreur 439 apparait (Un composant ActiveX
ne peut en créer un autre). J'aimerais connaître les raisons de cette erreur
? Sachant que je ne souhaite pas enregistrer la dll dans la base de registre
(regsvr32) car j'aimerais que le tout reste dynamique (les clients ne sont
pas admin sur leur poste donc ils ne peuvent pas exécuter ce genre de
commande)
De plus lors d'une modification de la dll en local je dois recompiler mon
exe sinon il plante mais pas en Access. Ceci va à l'encontre de l'utilité des
dlls. Quelle en est la raison ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Guichard
Steff a écrit :
Bonjour,
Bonsoir,
De plus lors d'une modification de la dll en local je dois recompiler mon exe sinon il plante mais pas en Access. Ceci va à l'encontre de l'utilité des dlls. Quelle en est la raison ?
Il faut que la DLL garde la même "signature" d'une version à l'autre. En gros, ça veux dire qu'il faut que tu recompile avec le mode compatibilité binaire activé. Sinon, tu vas te retrouver avec des CLSID différents d'une version à l'autre.
Vincent Guichard
Steff a écrit :
Bonjour,
Bonsoir,
De plus lors d'une modification de la dll en local je dois recompiler mon
exe sinon il plante mais pas en Access. Ceci va à l'encontre de l'utilité des
dlls. Quelle en est la raison ?
Il faut que la DLL garde la même "signature" d'une version à l'autre. En
gros, ça veux dire qu'il faut que tu recompile avec le mode
compatibilité binaire activé. Sinon, tu vas te retrouver avec des CLSID
différents d'une version à l'autre.
De plus lors d'une modification de la dll en local je dois recompiler mon exe sinon il plante mais pas en Access. Ceci va à l'encontre de l'utilité des dlls. Quelle en est la raison ?
Il faut que la DLL garde la même "signature" d'une version à l'autre. En gros, ça veux dire qu'il faut que tu recompile avec le mode compatibilité binaire activé. Sinon, tu vas te retrouver avec des CLSID différents d'une version à l'autre.
Vincent Guichard
Steff
Ok merci Vincent. La modification est prise en compte avec le mode binaries. Mais mon problème de déploiement persiste...
"Vincent Guichard" a écrit :
Steff a écrit : > Bonjour,
Bonsoir,
> De plus lors d'une modification de la dll en local je dois recompiler mon > exe sinon il plante mais pas en Access. Ceci va à l'encontre de l'utilité des > dlls. Quelle en est la raison ?
Il faut que la DLL garde la même "signature" d'une version à l'autre. En gros, ça veux dire qu'il faut que tu recompile avec le mode compatibilité binaire activé. Sinon, tu vas te retrouver avec des CLSID différents d'une version à l'autre.
Vincent Guichard
Ok merci Vincent. La modification est prise en compte avec le mode binaries.
Mais mon problème de déploiement persiste...
"Vincent Guichard" a écrit :
Steff a écrit :
> Bonjour,
Bonsoir,
> De plus lors d'une modification de la dll en local je dois recompiler mon
> exe sinon il plante mais pas en Access. Ceci va à l'encontre de l'utilité des
> dlls. Quelle en est la raison ?
Il faut que la DLL garde la même "signature" d'une version à l'autre. En
gros, ça veux dire qu'il faut que tu recompile avec le mode
compatibilité binaire activé. Sinon, tu vas te retrouver avec des CLSID
différents d'une version à l'autre.
Ok merci Vincent. La modification est prise en compte avec le mode binaries. Mais mon problème de déploiement persiste...
"Vincent Guichard" a écrit :
Steff a écrit : > Bonjour,
Bonsoir,
> De plus lors d'une modification de la dll en local je dois recompiler mon > exe sinon il plante mais pas en Access. Ceci va à l'encontre de l'utilité des > dlls. Quelle en est la raison ?
Il faut que la DLL garde la même "signature" d'une version à l'autre. En gros, ça veux dire qu'il faut que tu recompile avec le mode compatibilité binaire activé. Sinon, tu vas te retrouver avec des CLSID différents d'une version à l'autre.