Discussion :

[cogimaflorian]

Bonjour,

Cela fait 2 jours que je bloque sur un problème.
J'essaye de tester le chargement dynamique de package via ce tutorial :

http://edn.embarcadero.com/article/27178

Je n'arrive pas à faire fonctionner les exemples 2 et 3. Je ne comprend pas la partie avec les package d'exécution, etc ... Quand j'arrive enfin à le faire fonctionner, celui ci ne fonctionne que sur le poste ayant Delphi, car il stipule qu'il ne trouve pas le fichier rtl170.dpl sur un autre poste.
C'est à s'arracher les cheveux.

Quelqu'un s'est déjà pencher sur ce type d'utilisation ?

Pour info je suis sous XE3.

[ThWilliam]

Bonsoir,

Tu dois installer rtl170.bpl sur ton autre poste.

Téléchargeable sur le net, notamment ici :
http://www.opendll.com/index.php?fil...ponent-Package

Non testé. Analyse antivirus souhaitable.

Tu trouveras aussi les instructions d'installation.

Cordialement
Thierry

[Ph. B.]

Bonjour,

Tu dois installer rtl170.bpl sur ton autre poste.

Téléchargeable sur le net, notamment ici :
http://www.opendll.com/index.php?fil...ponent-Package

Non testé. Analyse antivirus souhaitable.

Plutôt que télécharger la bibliothèque, il est préférable de prendre celle qui est sur le poste et de la déployer en même temps que l'application ou la bibliothèque qui l'utilise...
Pour XE3 et une installation avec les paramètres par défaut, ce devrait être dans : C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin ou bin64

[cogimaflorian]

Alors oui, j'ai réussi faire fonctionner mon programme après avoir mis ce fichier à la racine de mon exe.
Mais est ce obligatoire lorsque l'on travaille avec des packages dynamiques ? Dans nos applications actuelles, on ne livre pas ces fichiers bpl et pourtant l'application fonctionne sur tout les postes. La seule différence est que j'ai été obliger de cocher "Lier avec les packages d'exécution" et rajouter uniquement "vcl" dans les packages du projet pour que le chargement dynamique fonctionne. Sans quoi ça ne fonctionnais pas.

Je récapitule :
- Exe actuel : "Lier avec les packages d'exécution" décoché. Les exe fonctionne sur tout les postes, là aussi ou les fichier bpl n'existe pas. Notre exe fait environ 20 Mo.
- Test sur les packages dynamique : obliger de cocher "Lier avec les packages d'exécution" et d'ajouter "vcl" dans les package sans quoi la fonction GetClass('TFormOrder') (de l'exemple du premier post) me renvoie toujours nil. Or, dès que j'active "Lier avec les packages d'exécution" dans mon projet principale, l'exe ne fait plus que 11 Mo et ne fonctionne que sur le poste où les fichier rtl et vcl .bpl sont installés.

Est-ce que j'ai louper quelque chose ou pas ?

J'avoue ne pas tout comprendre. L'idée finale étant d'avoir une application avec chargement dynamique de package fonctionnant sur tous les postes, fichier rtl et vcl . bpl (et autres) non installé.

Rappel de l'architecture désiré (fonctionnant sur tout les postes, sans fichier bpl, hormis ceux développé pour l'application)

[SergioMaster]

Bonjour,

Je crois que vous n'avez pas saisi le sens du mot package dynamique . Un package dynamique n'est ni plus ni moins qu'une dll , il ne vous viendrait pas à l'idée de distribuer un programme sans ses dlls associées , il en est de même pour les 'packages dynamiques' .

Pourquoi le programme compilé avec les packages est moins gros : tout simplement parce que ceux-ci ne sont pas intégrés avec l'exe

Par contre, il n'est pas obligatoire que ces packages soient dans le même répertoire que l'application , ils peuvent se trouver dans un répertoire système ou à tout le moins dans un répertoire indiqué dans les chemins de recherche .

en exemple : j'ai 3 programmes exe pour une application , mes trois programmes ont été compilés avec les packages ( "Lier avec les packages d'exécution" coché) vcl,rtl
je distribuerais mes 3 exe , les vclxxx.dpl et rtlxxx.dpl associés (ainsi que les .fr correspondant d'ailleurs) par contre pour l'installation admettons que chaque programme aille dans un répertoire différent (pour le fun)

C:\APPLICATION
C:\APPLICATION\VCLXXX.DPL
C:\APPLICATION\VCLXXX.FR
C:\APPLICATION\RTLXXX.DPL
C:\APPLICATION\RTLXXX.FR
C:\APPLICATION\PROGRAMME1\programme1.EXE
C:\APPLICATION\PROGRAMME2\programme3.EXE
C:\APPLICATION\PROGRAMME3\programme3.EXE

avec , ajouté aux chemins de recherches "classiques" c:\windows\system32,c:\windows\Syswow64 le chemin c:\application

les seuls hics de cette démarche :
- si l'on fait un changement dans une des bibliothèque distribuées (je pense en particulier à la dclstdxxx.dpl) enfin, cela, avec une bonne "hygiène de logiciel" ne peut pas arriver n'est-ce pas
- l’internationalisation , vous avez remarqué que je fait également copier les .fr des bibliothèques, ceci pour ne pas avoir la surprise de voir un bouton "anglais" par exemple Cancel, mais bien un joli bouton Annuler . Maintenant, quid si vous allez mettre votre application sur un PC espagnol ? hé bien ce pC se retrouve avec, à nouveau le Cancel , sauf a avoir distribué les .sp correspondant (je ne suis pas sur de l'extension, mais c'est pour l'exemple)

n.b. les xxx correspondent à la version Delphi

[edit] en me relisant je vois que je parle de dpl (c'est ce que je faisais avec D3) , dpl, bpl, même combat (je ne me rappelle plus à partir de quelle version on est passé de dpl à bpl)

Dans le cas du shéma : il faudrait que cst_data et cst_order soit compilé sans les packages et que application soit compilé avec les packages cst_data et cst_order (distribués bien sûr)

ce qui m'amène d'ailleurs à une question aux membres , serait-ce concevable de partager une connexion BDD aux 3 programmes de mon exemple via cst_data ? Que se passerait-il quand un des trois programmes se termine ?
par exemple si PROGRAMME1 est lancé en premier et donc ouvre la connection à la BDD via une dll (bpl dans ce cas)
si on lance PROGRAMME2 , si j'ai bien compris, la connexion à la BDD reste celle crée par PROGRAMME1
si PROGRAMME1 est fermé (sans fermeture de la connexion bien sur) que se passe t-il ?
Je dois avouer n'avoir jamais essayé , quelqu'un a t-il fait cette expérience ?

[cogimaflorian]

Ah oui je comprend mieux.

Donc je pense que la réponse que je cherchais est de renseigner "chemins de recherches". La démarche est donc : Projet / Options / Compilateur Delphi / Chemin de recherche c'est bien ça ?

Etant donner que je vais faire des package dynamique, je vais donc devoir fournir aux utilisateurs les fichiers bpl que nous auront créé + ceux de Delphi que l'on utilise (vcl, rtl, ...).
J'aimerai avoir une architecture finale comme cela :

C:\APPLICATION
C:\APPLICATION\programme1.exe
C:\APPLICATION\packages\packageperso1.bpl
C:\APPLICATION\packages\packageperso2.bpl
C:\APPLICATION\systeme\vcl170.bpl
C:\APPLICATION\systeme\rtl170.bpl

Peut on indiquer des chemins relatifs à l'exe pour aller chercher les bpl perso + ceux nécessaire au lancement de l'application ?

Edit : Je viens de faire le test en renseignant dans chemins de recherches : ./systeme et en mettant dedans les fichiers vcl170.bpl, rtl170.bpl, ... et au lancement du logiciel sur un poste sans Delphi, il me dit que le fichier rtl170.bpl est introuvable.

Merci d'avance,
J'avoue ne pas avoir tout saisie mais je pense que j'avance dans la bonne direction ...

[SergioMaster]

Donc je pense que la réponse que je cherchais est de renseigner "chemins de recherches". La démarche est donc : Projet / Options / Compilateur Delphi / Chemin de recherche c'est bien ça ?

non non, pas les chemins de recherche du compilateur Delphi , mais ceux des variables d'environnement du système

en fait j'ai appuyé sur envoi avant d'avoir fini mon premier Post et l'ai repris en modifications (je sais pas bien) et je le refait encore

dans ton cas le chemin contiendra (variable d'environnement) PATH=....,C:\APPLICATION\packages

[cogimaflorian]

Et est ce qu'on peut stipuler dans l'exécutable Delphi que je vais compiler où chercher les bpl, ou alors modifier la variable d’environnement du système ?

Parce que si je comprend bien en l'état, si je distribue mon application sur 200 postes, les 200 postes sont obligé de modifier les variables d'environnement de leur poste pour pointer sur les fichier vcl, rtl, ... que je leur aurait distribué.

Il n'y a pas plus simple en définissant dans l'exécutable de les chercher à un endroit relatif à cet exe ?

Edit : Effectivement, en ajoutant dans les variables d'environnement système le chemin vers mes bpl perso et vcl, ... , plus de message. Par contre, je trouve la démarche compliqué, surtout quand on distribuer une application.

[SergioMaster]

Parce que si je comprend bien en l'état, si je distribue mon application sur 200 postes, les 200 postes sont obligé de modifier les variables d'environnement de leur poste pour pointer sur les fichiers vcl, rtl, ... que je leur aurait distribué.

mais pourquoi diable les vcl, rtl etc ...? uniquement bpl

Il n'y a pas plus simple en définissant dans l'exécutable de les chercher à un endroit relatif à cet exe ?

non je ne crois pas , sauf à mettre les BPL dans le répertoire système de Windows (selon la version 32/64 bits)

modifier les variables d'environnement de leur poste : compliqué, surtout quand on distribue une application.

rien qu'un installateur ne puisse résoudre

[cogimaflorian]

Oui oui juste en définissant le dossier de mes bpl.

C'est vraiment qu'actuellement nous déployons nos solutions sans tenir compte de ces variables. Ça risque d'être contraignant pour vous de devoir définir les variables à chaque déplacement de nos exécutable. l'idéal aurait été de les mettre dans un sous dossier de nos applications et que l'exécutable sache où aller les chercher.

En tout cas merci pour tes réponses,
Je comprend un peu mieux le processus de package dynamique dans Delphi.

Merci