IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C# Discussion :

Handle d'objet managé c# 1.1


Sujet :

C#

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 57
    Par défaut Handle d'objet managé c# 1.1
    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

  2. #2
    Membre Expert Avatar de Guulh
    Homme Profil pro
    Inscrit en
    Septembre 2007
    Messages
    2 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Septembre 2007
    Messages : 2 160
    Par défaut
    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).

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 57
    Par défaut
    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.

  4. #4
    Inactif  
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Janvier 2007
    Messages
    6 604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Janvier 2007
    Messages : 6 604
    Par défaut
    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).

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    57
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 57
    Par défaut
    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.

  6. #6
    Membre Expert Avatar de Guulh
    Homme Profil pro
    Inscrit en
    Septembre 2007
    Messages
    2 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Septembre 2007
    Messages : 2 160
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 26/02/2008, 12h54
  2. Tableau d'objet managé
    Par alexadvance dans le forum Visual C++
    Réponses: 8
    Dernier message: 23/03/2007, 09h20
  3. Réponses: 1
    Dernier message: 15/02/2007, 18h22
  4. [C++]sizeof d'un objet managée
    Par Akta3d dans le forum C++/CLI
    Réponses: 4
    Dernier message: 22/12/2006, 12h15
  5. Probleme utilisation d'Objets managé grace a gcroot
    Par pepefourras dans le forum MFC
    Réponses: 4
    Dernier message: 16/05/2006, 00h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo