Discussion :

[Yogy]

Bonjour, j'ai 2 projets A et B qui accèdent à une classe statique d'une 3 eme projet C.
Les 2 premiers projets accedent bien aux propriétés de la classe statique et peuvent mettre à jour.
Mais si B essaye de lire la propriété que vient de mettre à jour A , la variable apparait comme null....

J'ai essayé de faire une petite solution avec 3 projets pour tester, et A voit bien la mise a jour que vient de faire B sur C et inversement.

Je ne comprend pas le pourquoi de ce comportement !!

A noter que B est une application console avec juste un static void Main.
A est une application windows.
Et C une classe statique. A et B reférencent C.

[Guulh]

Et C une classe statique. A et B reférencent C.

Et t'as bien A (projet de démarrage) qui référence B ? Parce que ça n'a aucune raison de ne pas marcher. Une propriété statique (d'une classe statique ou non d'ailleurs) existe en un unique exemplaire dans toute l'application (l'AppDomain si je ne me trompe), sans aucun lien avec les assemblies qu'elle a chargé.

[Yogy]

A est une application console et B une appli windows. et C une bibliotheque de classe. J'ai beau m'arracher mes petits cheveux je ne vois pas ce qui cloche..

[Yogy]

j'ai fait un autre test avec 2 projet winform repertoriant chacun la même classe statique .
Chaque appli modifie la classe statique. Et peut afficher la valeur de la propriété.
Et je vois que les 2 projets doivent avoir chacun leur propre instance de la classe statique. Puisqu'il peuvent la modifier mais jamais voir les modification de l'autre.
Du coup comment je peux faire pour que les 2 projets aient une zone mémoire commune ??

EDIT : j'ai mis une pièce jointe du projet de test. Est ce un comportement normal ou je fais qq chose mal ?

[Guulh]

A est une application console et B une appli windows. et C une bibliotheque de classe. J'ai beau m'arracher mes petits cheveux je ne vois pas ce qui cloche..

Je répète ma question (t'es pas clair ) : tu as bien, dans une même solution, un projet A qui référence B et C, un projet B qui référence C, et ta classe statique dans le projet C ?

Parce que si A et B sont dans deux solutions différentes, ça veut dire que chacune correspond à une appli, et il est donc normal qu'elle ne partage rien (et donc en particulier ta classe statique) puisque leurs zones mémoires sont disjointes.

[Yogy]

Euh non pas tout à fait.

A et B sont 2 appli winform.
C classe staique.
A reference C
B reference C.
C'est tout.
C'est la ou ça peche ?

J'ai modifier mon projet de test que j'ai mis en piece jointe. A reference B maintenant. Mais ça ne marche toujours pas.

[Sphax]

Comme le dit Guulh tes deux projets A et B lorsqu'ils sont lancés sont dans deux process windows différents, donc deux espaces mémoires différents dans lesquels deux "images" de ton assembly C vont être chargées, chacun la sienne. Pas moyen avec une classe statique de faire communiquer deux process.

Pour ça faut utiliser un moyen "externe" comme une base de donnée, ou faire du remoting (ou du wcf) , ou encore utiliser des zones mémoires partagées.

[Guulh]

Euh non pas tout à fait.

A et B sont 2 appli winform.
C classe staique.
A reference C
B reference C.
C'est tout.
C'est la ou ça peche ?

J'ai modifier mon projet de test que j'ai mis en piece jointe. A reference B maintenant. Mais ça ne marche toujours pas.

Donc ça veut dire que tu lances A.exe et B.exe l'un après l'autre ? parce que sinon, je vois pas comment le code de B peut être exécuté, s'il n'est pas référencé par le projet principal de ta solution.

[Yogy]

J'allais me pencher vers une base de données. Je crois que c'est ce que je vais faire du coup.....
Ou un fichier XML peut etre ?

[Guulh]

J'allais me pencher vers une base de données. Je crois que c'est ce que je vais faire du coup.....
Ou un fichier XML peut etre ?

Remoting, ou WCF (si tu es en framework >= 3) est probablement bien mieux adapté. Mais ça dépend de ton besoin : selon que tu veux échanger un cache de 150 Mo ou un booléen, la solution technique la plus pertinente change du tout au tout.

[Sphax]

J'allais me pencher vers une base de données. Je crois que c'est ce que je vais faire du coup.....
Ou un fichier XML peut etre ?

ça dépend de ce que tu veux faire. Tu peux utiliser un fichier si un seul des process va écrire dedans et l'autre uniquement lire, sans ça tu vas devoir gérer des problèmes compliqués de concurrence d'accès, écrasement de données, alors que les bases de données offrent cette gestion (transaction tout ça...).

[dadal]

Hello,
En fait c'est possible que tu utilise pas vraiment la même dll physique, mais une copie.
Copie

Code :

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

1
2
            
Console.WriteLine(System.Reflection.Assembly.GetAssembly(typeof(ClassLibrary1.Class1)).Location);

au début de chaque console application (en remplaçant "ClassLibrary1.Class1" par ta classe). Ca devrais t'afficher le chemin de ta dll réelement utilisé, qui devrait être différent les 2 fois.
Ensuiteje crois qu'il faut trafiquer dans les options de build pour que tes 2 projets utilisent les mêmes. (c'est ou j'en suis pour le moment en tout cas)

[Guulh]

Hello,
En fait c'est possible que tu utilise pas vraiment la même dll physique, mais une copie.

Même, ça change rien à son souci : une assembly n'est qu'un bout de code dans un fichier. Elle n'a pas d'espace mémoire propre, et les classes qu'elle contient existent dans la mémoire du process qui utilise l'assembly.

[Yogy]

ça dépend de ce que tu veux faire. Tu peux utiliser un fichier si un seul des process va écrire dedans et l'autre uniquement lire, sans ça tu vas devoir gérer des problèmes compliqués de concurrence d'accès, écrasement de données, alors que les bases de données offrent cette gestion (transaction tout ça...).

en fait je compte acceder à des logs. Je vais utiliser une bdd, comme ça je pourrai avoir 1 trace meme apres utilisation de l'appli....
merci pour votre aide en tous cas.