Discussion :

[Papy214]

Je suis confronté à un problème étrange avec SSL.
Un de mes programmes déclenche une erreur systématique sur les postes de mes collègues mais pas sur le mien.
Il s'agit d'un logiciel qui génère un PDF et l'envoie sur un site WEB en https avec le composant TIdHTTP.
Au déclenchement de l'envoi, les autres postes reçoivent le message:
"Impossible de charger la bibliothèque SSL"
Ils ont pourtant les mêmes fichiers que moi au même endroit sur leur poste.
Sur mon poste, aucun problème !

La chose étrange c'est que j'ai tenté re renommer les dll dans la répertoire où se trouve l'exe et ça fonctionne quand même. Ce qui me parait normal vu que de versions des dll concernées, j'en ai plusieurs sur mon poste et que Windows doit forcément en trouver une dans les différents chemins possibles.

Maintenant, la question est : pourquoi 2 installations identiques sur 2 postes différents ne fonctionnent pas de la même manière. Sur mon poste, aucune erreur, sur les autres (testés sur 3 différents), erreur.
Pourquoi mon programme ne peut pas charger ces dll alors qu'elles sont sous son nez (même répertoire).

Pour essayer de comprendre, j'ai demandé au collègue de donner tous les droits à tout le monde sur le dossier et même de lancer le programme en mode administrateur, cela ne change rien.

La seule différence entre eux et moi c'est que mon poste "Delphi" est encore sous Windows 8.1 et eux sont en W10. Est-ce que ça pourrait venir de là ?

Toute idée sera bonne à prendre parce que là je ne sais plus trop quoi faire pour débloquer la situation :-(

[ShaiLeTroll]

Essaye de forcer IdOpenSSLSetLibPath avant l'appel à LoadOpenSSLLibrary (normalement c'est uniquement à partir du moment où un objet qui requiert le SSL en a besoin) lors de la création d'un TIdSSLContext par le TIdSSLIOHandlerSocketOpenSSL (une fois la connexion TCP IP ouverte, cela utilise la DLL pour le Hanshake et c'est là que se produit l'exception)

Je me suis greffer sur IdSSLOpenSSLHeaders.GetCryptLibHandle pour utiliser PEM_read_bio_PUBKEY qui n'était pas déclaré dans ma version de Indy




Pour ton exe, vérifie le dossier de démarrage si cela utilise un raccourci, cela peut influencer les chemins relatifs, en général, je préfère toujours utiliser explicitement Application.ExeName pour localiser le dossier de l'exe que me baser sur le CurrentDir.

Tous les developpeurs compilent sur la même architecture ? 32 vs 64 ?
DPROJ identique (les variables d'environnement bien utile pour partager le même DPROJ mais des chemins différents sur chaque poste)
En débogage, Delphi est tout de même assez intrusif en particulier pour l'environnement hérité (il est 32 bits encore le IDE ?)

[Papy214]

J'ai testé, toujours le même problème. C'est à n'y rien comprendre.
J'ai même fait un simple bout de code de test dans une appli autonome, ça fonctionne chez moi et pas chez les autres.
Pour la différence entre Windows 8 et 10, j'ai essayé le même programme de test sur mon poste à la maison. Ça fonctionne mais la même chose bloque toujours chez les autres.
J'ai pensé à un effet de l'antivirus mais on a le même.
Comme tout le monde, j'ai souvent été confronté à des casse-têtes mais celui-là il est assez gratiné :-(

[SergioMaster]

Bonjour,
tu oublies aussi le 32/64 bits ce qui complexifie un peu plus le problème

[Papy214]

Tous les postes sont en 64.
Les dll sont bien les bonnes versions et le code est bien la version 32 bits générée par Delphi.
Et niveau code, je peux difficilement faire plus court pour tester.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
    IdOpenSSLSetLibPath(TPath.GetDirectoryName(Application.ExeName));
    if LoadOpenSSLLibrary then
       ShowMessage('Librairies SSL chargées')
    else
      raise Exception.Create('Les librairies SSL ne peuvent être chargées');

Au moins en faisant ça, ça m'a permit de voir que le programme complet n'est pas en cause.

[SergioMaster]

Et, puisque les programmes sont en 32 bits, les Dlls sont bien en 32 bits ?