Conflit Système d'exploitation/installation de DLL [Résolu]

[seikaLogiciel]

Bonjour à tous,

mon client utilise présentement un serveur « Windows Server 2008 R2 Standard » et lorsque j'essaie d'installer les DLLs d'Acomba via l'exécutable WRInfo.exe ou via la section « Info » dans Acomba, la sauvegarde de la configuration fonctionne sans problème.

Par contre, lorsque j'essaie de synchroniser des données d'Acomba dans mon programme je reçois ce message d'erreur :
« La récupération de la fabrique de classe COM pour le composant avec le CLSID-{0000018B-0000-000F-1000-000ACOBAC0127} a échoué en raison de l'erreur suivante : 80040154. »

Me prouvant hors de tout doute que la dll n'est pas dans les registres du serveur.

Merci de votre aide.

[PlanteG]

Bonjour,

j'ai remarqué un problème similaire sous Windows 7 64 bits, à la différence que j'avais un message d'erreur dès l'enregistrement du 1er DLL. Dans mon cas, pour enregistrer les DLL j'ai réinstallé la même version d'Acomba en recourant au setup.exe dans \NetMAJ. Êtes-vous en mesure de faire la même chose ? Il semble que setup.exe et wrinfo.exe n'utilisent pas la même fonction d'API. Peut-être que regsvr.exe/regsvr32.exe pourrait être utilisé, mais je ne sais si les DLL du SDK fonctionnent avec cette commande.

[seikaLogiciel]

Salut PlanteG,

la commande regsvr32.exe fonctionne mais fonctionne différemment sur un système d'exploitation 64 bits.

Après quelques recherches, voici ce que j'ai trouvé sur le sujet :
-Lorsqu'on enregistre une dll 32-bits sur un serveur 64-bits, il faut spécifier explicitement le regsvr32.exe que l'on veut utiliser car il y en a 2 sur un système d'exploitation 64-bits.
-Par défaut, le bon exécutable pour enregistrer les dll 32-bits se retrouve ici : C:\Windows\syswow64\
-Pour installer la dll en question, il faudrait donc faire :

1. Cliquer sur Démarrer.
   Choisir «Exécuter».
   Taper C:\Windows\Syswow64\regsvr32.exe [Le chemin complet de votre dll a installé (par défaut à titre d'exemple : "C:\Fortune\Acomba\SDK\AcoSDK.dll")]

À noter que si vous ne spécifier pas le chemin au complet, windows utilise par défaut l'exécutable situé sur c:\windows\system32\regsvr32.exe.

En résumé, c'est peut-être un peu mélangeant, mais bon :
C:\Windows\Syswow64\regsvr32.exe --> N'enregistre que des DLL 32-bits.
C:\windows\system32\regsvr32.exe. --> N'enregistre que des DLL 64-bits. (Défaut)
Regsvr32.exe --> N'enregistre que des DLL 64-bits, car il utilise l'exécutable par défaut du système d'exploitation 64-bits.

Je crois que Microsoft aurait dû mettre par défaut les bon exécutable dans les bons dossiers pour moins de confusion, mais bon c'est comme ça alors hehe.

Note importante, ce ne sont présentement que des spéculations mais j'attends des tests prochains de ce que j'avance. Je viendrais confirmer sur le forum si tout s'est bien déroulé.

Dans le cas contraire, j'essaierais ta méthode PlanteG, mais j'aurais p-e de la difficulté à l'appliquer à 100% car le client pour qui je dois installer cette dll a installé Acomba sur un serveur et le poste de travail où je dois installer la DLL est sur un autre serveur.

Merci beaucoup de ton aide toujours très apprécié.

[seikaLogiciel]

Après test, aucun résultat satisfaisant.

-J'ai tenté d'enregistré les DLLs en spécifiant le chemin complet c:\windows\syswow64\regsvr32.exe sans succès.
-J'ai tenté de lancé l'exécutable Setup.exe dans le dossier NetMaj avec une image locale prise mais j'ai reçu un message d'erreur "Vous n'avez pas le droit d'installer cette version.
-J'ai tenté d'exécuter l'exécutable WRInfo.exe avec "Exécuter en tant qu'administrateur" et cela n'a rien changé.

La version d'Acomba utilisé est la 9.41.0.1 datant du 23 décembre 2009.

Si vous avez d'autres idées pour enregistré la dll utilisé par le SDK (AcoX0127.dll), je suis preneur.

[PlanteG]

Le message qui dit que "Vous n'avez pas le droit d'installer cette version." signifie habituellement que l'image d'installation utilisée est celle d'une autre compagnie. Je m'explique. L'entreprise AAA (licence enregistrée à AAA) procède à la création d'une image locale. L'image de AAA est déposée dans le répertoire \NetMAJ de l'entreprise BBB. Lorsque l'on essaie d'exécuter setup.exe chez l'entreprise BBB, alors ce message s'affiche. Les fichiers d'installation sont personnalisés pour l'entreprise qui les télécharge, et ne fonctionne pour une autre entreprise.

Pour ce qui est de l'enregistrement des DLL selon cet autre message regsvr32.exe fonctionnerait .

[Lartis]

Bonjour,

Une précision: il faut aussi utiliser l'administrateur de DSN ODBC 32 bits, soit celui qui se trouve dans C:\Windows\SysWOW64\odbcad32.exe.

Le odbcad32.exe par défaut (celui 64 bits) ne verra ni le driver ni les DSN 32 bits.

Quelques tests à faire:
Menu Info - A propos, onglet SDK, sélectionner le bon répertoire et faire "sauvegarder la configuration" (vous l'avez sans doute fait)
Menu Info, case "Fonction": tapez "odbcon" et cliquer sur OK. Ça correcte quelque fois le problème. Je ne sais pas exactement ce que ça fait.

Regardez avec C:\Windows\SysWOW64\odbcad32.exe si vous voyez le driver "Acomba ODBC Driver", version 25 (la plus récente).

Si oui, essayer de créer un system DSN et de le tester. Si le driver n'est pas la, il faudrait faire d'autres tests, je ne sais pas quel serait le problème.

[seikaLogiciel]

Bonjour Lartis,

y-a-t'il un lien direct entre l'ODBC et le SDK? Dans mon cas, j'utilise le SDK dans mon programme.

D'une façon ou d'une autre, je vais essayer ce que tu me proposes et j'en redonne des nouvelles dès que possible.

[PlanteG]

Il y a un lien entre le pilote ODBC et le SDK car le pilote ODBC utilise le SDK. Si le SDK n'est pas installé, les DLL pas enregistrés, ODBC ne fonctionne pas.

Comme vous programmez pour le SDK, vous n'avez pas besoin de l'ODBC. Sylvain a mentionné l'ODBC pensant peut-être que vous l'utilisiez, et à cause du lien qui les unit .

[seikaLogiciel]

J'ai essayé les méthodes suggérer par Sylvain, mais cela n'a rien donné.

Effectivement, j'utilise le SDK et non l'ODBC.

Si ça peut aider par contre, j'ai remarqué que la version de L'ODBC était la version 15 datant du 2008-12-03 et donc une version antérieur à la version 25.

Malgré tout ces tests, le serveur virtuel Windows Server 2008 R2 Standard ne semble pas vouloir enregistrer les DLLs d'Acomba.

Je fais présentement le suivi avec Fortsum et j'espère qu'ils auront une solution à me proposer.

Si vous avez d'autres idées, elles sont le bienvenues.

Merci du temps et de l'énergie que vous investissez à m'aider à régler mon problème.

[seikaLogiciel]

J’ai finalement trouvé la solution à mon problème et la voici :

En résumé, ce n’est pas l’installation des DLLS qui faisait défaut, mais j’ai appris à mes dépends qu’il fallait absolument compiler le programme en x86 (32 bits) pour qu’il puisse utiliser les dlls d’Acomba.

Ce n’est pas important que tous les projets soient compilés ainsi, mais il faut que le programme principale (celui avec lequel l’application s’ouvre), soit compiler ainsi.

Pour ce faire :
1) Clique-droit sur le projet en question et choisir Propriétés.
2) Dans l’onglet « Compile », cliquer sur le bouton « Advanced Compiler Settings » en bas à gauche de l’écran.
3) Choisir « x86 » comme Target CPU.

À noter que j’utilise Visual Studio 2008.

En espérant avoir aidé tous les autres qui pourrait avoir rencontré le même problème.

[Contenu sponsorisé]