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 :

Unicité des dlls en mémoire.


Sujet :

C#

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Mars 2002
    Messages
    312
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2002
    Messages : 312
    Par défaut Unicité des dlls en mémoire.
    Bonjour,
    J'ai développé une assembly qui logue des informations que lui envoie des applications.
    Or dans certains cas, la dll provoque une exception afin d'indiquer que le fichier est utilisé par un autre processus, or il n'y a que ma dll qui l'utilise et elle se trouve dans le GAC ce qui pour moi voudrait dire qu'elle se trouve une seul fois en mémoire non ? J'ai bien rajouté un mutex mais rien à faire.

    Y a t il un moyen afin de s'assurer que ma dll soit instancier un fois et utilisé par plusieurs instances d'application ?

    Merci d'avance

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Par défaut
    Citation Envoyé par bleuerouge Voir le message
    Or dans certains cas, la dll provoque une exception afin d'indiquer que le fichier est utilisé par un autre processus, or il n'y a que ma dll qui l'utilise
    ça n'a rien à voir avec le fait qu'elle soit dans le GAC ou qu'elle soit une ou plusieurs fois en mémoire... C'est une question de process, pas de DLL. Même si la DLL est une seule fois en mémoire, si plusieurs process l'utilisent en même temps, tu peux rencontrer le problème.

    En fait, le message qui dit que le fichier est utilisé par un "autre" processus est trompeur, car en fait ça peut très bien être le même process (et a priori c'est le cas). Tu as probablement déjà ouvert le fichier et oublié de le fermer, donc quand tu essaies de l'ouvrir à nouveau, ça pète...

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Mars 2002
    Messages
    312
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2002
    Messages : 312
    Par défaut
    Citation Envoyé par tomlev Voir le message
    En fait, le message qui dit que le fichier est utilisé par un "autre" processus est trompeur, car en fait ça peut très bien être le même process (et a priori c'est le cas). Tu as probablement déjà ouvert le fichier et oublié de le fermer, donc quand tu essaies de l'ouvrir à nouveau, ça pète...
    Voici le code qui pose problème :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
     
     
    try
    {
       FluxFichier = new StreamWriter(Chemin, true);
     
       FluxFichier.WriteLine(monlog);
     
       FluxFichier.Flush();
    }
    catch (Exception ex)
    {
    Trace.TraceError("LogFile.Trace_Insert - Erreur " + ex.Message);
    result = -1;
    throw new Exception("LogFile - Impossible d'inscrire dans le fichier :" + Chemin, ex);
    }
    finally
    {
    FluxFichier.Close();
    FluxFichier.Dispose();
    }
    Mon fichier est systématique clos et à la fin de l'écriture d'un log. J'ai rajouté un lock(this), ça ne fonctionne pas mieux.

  4. #4
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Par défaut
    FluxFichier est une variable locale ou un champ de la classe ? Si c'est un champ ça peut effectivement poser des problèmes...

  5. #5
    Membre éclairé
    Profil pro
    Inscrit en
    Mars 2002
    Messages
    312
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2002
    Messages : 312
    Par défaut
    Citation Envoyé par tomlev Voir le message
    FluxFichier est une variable locale ou un champ de la classe ? Si c'est un champ ça peut effectivement poser des problèmes...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    public StreamWriter FluxFichier;
    Un champ public de ma classe

  6. #6
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Par défaut
    Citation Envoyé par bleuerouge Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    public StreamWriter FluxFichier;
    Un champ public de ma classe
    Très mauvaise idée, et même doublement...

    D'une part, les champs publics, c'est mal ; c'est une violation de l'encapsulation, ça permet à n'importe quel code externe à ta classe de modifier sans aucun contrôle l'état interne de la classe.

    D'autre part, cette variable n'a pas besoin d'être un champ (tu pourrais obtenir le même résultat avec une variable locale), et le fait que ce soit un champ va poser des problèmes si ta méthode est appelée en même temps à partir de différents threads, car les 2 threads vont partager la même variable et risquent de se "marcher sur les pieds". Je ne sais pas si c'est la cause de ton problème, mais c'est une explication plausible...

Discussions similaires

  1. Comportement mémoires des dll linkées ou externes ?
    Par lpierard dans le forum Visual C++
    Réponses: 2
    Dernier message: 26/11/2009, 01h21
  2. Priorité de recherche des DLLs
    Par patapetz dans le forum Windows
    Réponses: 3
    Dernier message: 10/09/2003, 18h44
  3. Appel à des fonctions incluses dans des DLL
    Par Greybird dans le forum Langage
    Réponses: 3
    Dernier message: 26/05/2003, 13h33
  4. Réponses: 27
    Dernier message: 03/02/2003, 12h27
  5. [] [Install] Problème de mise à jour des dll
    Par pepper dans le forum Installation, Déploiement et Sécurité
    Réponses: 4
    Dernier message: 23/01/2003, 22h34

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