Discussion :

[chental]

Bonjour à tous,

Je suis entrain de développer trois applications qui se partageront une DLL unique responsable d'accès aux données.

Cette DLL contient une propriété : User_Connected de type booléen qui avertit si l'utilisateur en cours est connecté ou non à la base de données.

Ma problématique :
Lorsque je démarre une des trois applications, je me connecte à la db et je charge mon dataset.
Quand j'essaie de démarrer la deuxième ou la troisième application, je n'arrive pas à récupérer le handle de la classe de la dll qui s'est déjà connectée à la DB, quelqu'un aurait-il une idée pour me permettre de pouvoir recupérer ce Handle ?
J'ai essayé avec gcnew, handleref et Gchandle, rien n'y fait.

Merci d'avance
Cordialement

[Guulh]

Une dll, c'est juste du code partagé. Ca n'a pas un process propre. La connexion à la base n'est pas détenue par la dll, mais par le process qui utilise la dll.

Apparemment, tu voudrais partager une connexion entre plusieurs applis : il te faudrait donc faire communiquer des process, et pour cela, les solutions les plus simples sont .Net remoting (framework <= 2) ou WCF (framework >= 3).

[chental]

Merci de ta réponse si rapide et claire.

Comme je le disais, la dll me sert à partager des ressources entre les trois applications et je ne voudrais pas réécrire la même chose trois fois en sachant que les données sont interdépendantes entre les applications.

C'est qu'il faut, c'est avoir la même instance de la classe principale de la Dll dans l'ensemble des deux applications qui démarreront après la première.

[Bluedeep]

Si je comprends je pense ton besoin, je ne comprends rien à ton histoire d'handle, du moins si il s'agit d'une DLL .Net avec des consommateurs .Net.

Je ne vois pas ce que les handles viennent faire là, à moins qu'il s'agisse d'une DLL en C++ non managé, mais là il eu fallut le spécifier.

Si tu veux qu'une des classes (c'est quoi la classe "principale" d'une DLL ???? je ne connais pas ce concept) de ta DLL partage une instance unique entre trois domaines d'application, la seule solution est (en 1.1) le remoting et il faut que ta DLL soit hostée dans un process séparé (serveur).

Sous toute réserve, je pense que c'est ton désign qui n'est peut être pas optimal.

Le besoin n'est pas limpide (une archi 3-Tier client lourd c'est limpide, mais, ici, on n'est pas sur que c'est ce que tu veux).

[chental]

Mille excuses pour le titre de cette discussion, peut être que je me suis mal exprimé.

En effet, j'ai trois applications qui vont tourner dans des espaces memoire diférents et namespace différents.

Pourtant, elles devront partager cette DLL où je n'expose publiquement qu'une classe que j'appelle classe principale. Les autres classes etant internes, mais là n'est pas le problème.

Imaginons une application de configuration des clients, l'autre des ventes et la dernière de gestion de stock.
Toutes ces applications sont interdependantes. Je ne m'imagine pas avoir accès aux données en demandant par exemple à l'utilisateur de saisir son mdp et login alors qu'il l'avait déjà fait une fois une des applications a été lancée.
Voilà ma problématique, il me faut avoir l'instance de la première connexion utilisée ainsi tout ce qui va avec, c'est le dataset concerné, les options de l'utilisateur, tout ce qui a été implémenté dans la DLL quoi !.

Je pense m'être exprimé assez clairement, en tout cas je l'espère.

[Guulh]

Mais comme je le disais tout à l'heure, une dll n'a pas d'espace mémoire propre. C'est juste que le code d'un exe instancie des objets définis dans cette dll, dans son espace à lui.

Donc si tu veux partager non seulement des types, mais aussi des instances de ces types, il te faut créer un process serveur, qui offrira des fonctionnalités dont tes trois exe seront clients. Et la solution technique la plus simple, c'est remoting ou WCF.

Et d'ailleurs, les namespace n'ont rien à voir. Un namespace, c'est juste le préfixe d'une classe ; c'est un concept objet, qui n'a aucun lien avec les process / exe / dll.