Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
dans les proprietes de mon projet, et j ai change mon type de sortie
de "application window" a "bibliotheque de classe".
Or lorsque j appele mon web service, j ai remarque qu il me retournait
les valeurs d'initialisation de mes variables, et non pas les valeurs
courantes, dynamique de l application en train de tourner.
Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
dans les proprietes de mon projet, et j ai change mon type de sortie
de "application window" a "bibliotheque de classe".
Or lorsque j appele mon web service, j ai remarque qu il me retournait
les valeurs d'initialisation de mes variables, et non pas les valeurs
courantes, dynamique de l application en train de tourner.
Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
dans les proprietes de mon projet, et j ai change mon type de sortie
de "application window" a "bibliotheque de classe".
Or lorsque j appele mon web service, j ai remarque qu il me retournait
les valeurs d'initialisation de mes variables, et non pas les valeurs
courantes, dynamique de l application en train de tourner.
> Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application.
Qu'entendez vous par "l'application en train de tourner"?
Ptlpn wrote:
> Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
> dans les proprietes de mon projet, et j ai change mon type de sortie
> de "application window" a "bibliotheque de classe".
>
> Or lorsque j appele mon web service, j ai remarque qu il me retournait
> les valeurs d'initialisation de mes variables, et non pas les valeurs
> courantes, dynamique de l application en train de tourner.
Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application. Votre question est peu claire:
est-ce qu'il y a un exe qui utilise cette bibliothèque de classes?
Qu'entendez vous par "l'application en train de tourner"? Quel type
d'application? Une application Web?
Pour répondre à votre question, il nous faudra plus de détails sur la
structure de l'ensemble.
> Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application.
Qu'entendez vous par "l'application en train de tourner"?
Ptlpn wrote:
> Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
> dans les proprietes de mon projet, et j ai change mon type de sortie
> de "application window" a "bibliotheque de classe".
>
> Or lorsque j appele mon web service, j ai remarque qu il me retournait
> les valeurs d'initialisation de mes variables, et non pas les valeurs
> courantes, dynamique de l application en train de tourner.
Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application. Votre question est peu claire:
est-ce qu'il y a un exe qui utilise cette bibliothèque de classes?
Qu'entendez vous par "l'application en train de tourner"? Quel type
d'application? Une application Web?
Pour répondre à votre question, il nous faudra plus de détails sur la
structure de l'ensemble.
> Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application.
Qu'entendez vous par "l'application en train de tourner"?
Ptlpn wrote:
> Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
> dans les proprietes de mon projet, et j ai change mon type de sortie
> de "application window" a "bibliotheque de classe".
>
> Or lorsque j appele mon web service, j ai remarque qu il me retournait
> les valeurs d'initialisation de mes variables, et non pas les valeurs
> courantes, dynamique de l application en train de tourner.
Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application. Votre question est peu claire:
est-ce qu'il y a un exe qui utilise cette bibliothèque de classes?
Qu'entendez vous par "l'application en train de tourner"? Quel type
d'application? Une application Web?
Pour répondre à votre question, il nous faudra plus de détails sur la
structure de l'ensemble.
> Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application.
Qu'entendez vous par "l'application en train de tourner"?
Ptlpn wrote:
> Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
> dans les proprietes de mon projet, et j ai change mon type de sortie
> de "application window" a "bibliotheque de classe".
>
> Or lorsque j appele mon web service, j ai remarque qu il me retournait
> les valeurs d'initialisation de mes variables, et non pas les valeurs
> courantes, dynamique de l application en train de tourner.
Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application. Votre question est peu claire:
est-ce qu'il y a un exe qui utilise cette bibliothèque de classes?
Qu'entendez vous par "l'application en train de tourner"? Quel type
d'application? Une application Web?
Pour répondre à votre question, il nous faudra plus de détails sur la
structure de l'ensemble.
> Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application.
Qu'entendez vous par "l'application en train de tourner"?
Ptlpn wrote:
> Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
> dans les proprietes de mon projet, et j ai change mon type de sortie
> de "application window" a "bibliotheque de classe".
>
> Or lorsque j appele mon web service, j ai remarque qu il me retournait
> les valeurs d'initialisation de mes variables, et non pas les valeurs
> courantes, dynamique de l application en train de tourner.
Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application. Votre question est peu claire:
est-ce qu'il y a un exe qui utilise cette bibliothèque de classes?
Qu'entendez vous par "l'application en train de tourner"? Quel type
d'application? Une application Web?
Pour répondre à votre question, il nous faudra plus de détails sur la
structure de l'ensemble.
> Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application.
Qu'entendez vous par "l'application en train de tourner"?
Ptlpn wrote:
> Ensuite, pour creer ma dll dont le web service a besoin, je suis alle
> dans les proprietes de mon projet, et j ai change mon type de sortie
> de "application window" a "bibliotheque de classe".
>
> Or lorsque j appele mon web service, j ai remarque qu il me retournait
> les valeurs d'initialisation de mes variables, et non pas les valeurs
> courantes, dynamique de l application en train de tourner.
Parce que le Web Service n'utilise visiblement pas la même instance de
la DLL (assembly) que l'application. Votre question est peu claire:
est-ce qu'il y a un exe qui utilise cette bibliothèque de classes?
Qu'entendez vous par "l'application en train de tourner"? Quel type
d'application? Une application Web?
Pour répondre à votre question, il nous faudra plus de détails sur la
structure de l'ensemble.
Parce que le Web Service n'utilise visiblement pas la même instance
de la DLL (assembly) que l'application.
Et c est la je pense que reside mon probleme: En fait, mon application
est une "Application windows", et donc elle n utilise pas de dll. J ai
cree la dll pour mon web service, mais mon appli ne l utilise pas.Qu'entendez vous par "l'application en train de tourner"?
En fait, j ai cree mon web service dans l espoir qu il me retourne la
valeur d une variable de mon application. Cette variable est
initialise a 100, puis est incrementee tout au long de l execution de
mon appli.
Parce que le Web Service n'utilise visiblement pas la même instance
de la DLL (assembly) que l'application.
Et c est la je pense que reside mon probleme: En fait, mon application
est une "Application windows", et donc elle n utilise pas de dll. J ai
cree la dll pour mon web service, mais mon appli ne l utilise pas.
Qu'entendez vous par "l'application en train de tourner"?
En fait, j ai cree mon web service dans l espoir qu il me retourne la
valeur d une variable de mon application. Cette variable est
initialise a 100, puis est incrementee tout au long de l execution de
mon appli.
Parce que le Web Service n'utilise visiblement pas la même instance
de la DLL (assembly) que l'application.
Et c est la je pense que reside mon probleme: En fait, mon application
est une "Application windows", et donc elle n utilise pas de dll. J ai
cree la dll pour mon web service, mais mon appli ne l utilise pas.Qu'entendez vous par "l'application en train de tourner"?
En fait, j ai cree mon web service dans l espoir qu il me retourne la
valeur d une variable de mon application. Cette variable est
initialise a 100, puis est incrementee tout au long de l execution de
mon appli.
> Il y a
effectivement un sérieux problème de design dans votre construction.
Ptlpn wrote:
>> Parce que le Web Service n'utilise visiblement pas la même instance
>> de la DLL (assembly) que l'application.
> Et c est la je pense que reside mon probleme: En fait, mon application
> est une "Application windows", et donc elle n utilise pas de dll. J ai
> cree la dll pour mon web service, mais mon appli ne l utilise pas.
>
>> Qu'entendez vous par "l'application en train de tourner"?
> En fait, j ai cree mon web service dans l espoir qu il me retourne la
> valeur d une variable de mon application. Cette variable est
> initialise a 100, puis est incrementee tout au long de l execution de
> mon appli.
Le mot espoir est particulièrement adapté dans ce cas :-)). Par quel
miracle voulez vous que les données de la DLL prennent comme par magie
les mêmes valeurs que les données correspondantes dans votre application
(exe)? Quelle relation peut-il exister entre les deux? Aucune. Il y a
effectivement un sérieux problème de design dans votre construction. La
bonne approche pourrait-être la suivante (je ne connais pas vos
contraintes donc j'avance au jugé):
- Votre application doit exposer un système de communication qui permet
à toute entité de code externe de l'interroger sur la valeur courante de
certaines données.
- Les méthodes de votre Web Service utilisent ce système pour interroger
l'appli quand cela est nécessaire.
Quant à ce système de communication, vous pouvez utiliser n'importe quel
mécanisme d'IPC qui conviendra le mieux à votre contexte:
- Objet singleton (à instance unique) qui contiendra les données en
question. L'objet (implémenté dans une DLL) expose des méthodes qui
permettent de positionner les valeurs (depuis l'appli) et de les lire
(depuis le Web Service). C'est ce qui ressemble le plus à ce que vous
essayez de faire. Voir par exemple
http://www.ondotnet.com/pub/a/dotnet/2002/11/11/singleton.html. Il y a
une seule instance de la DLL utilisée à la fois par l'application et le
Web Service.
- Fichier mappé en mémoire (Memory-mapped file - MMF) - qui me semble
adapté pour partager des données mais ce n'est pas une solution très
".Net".
- Sockets
- Pipe nommé
- Automation (vous faîtes de votre application un serveur COM exposant -
comme Excel ou Word - des méthodes qui retournent les valeurs en
question)
- Base de données (peut-être un peu lourd si il y a peu de données)
- Fichier partagé standard
- ...
Dans votre cas, les choses étant relativement simples, la première
solution est probablement la bonne.
> Il y a
effectivement un sérieux problème de design dans votre construction.
Ptlpn wrote:
>> Parce que le Web Service n'utilise visiblement pas la même instance
>> de la DLL (assembly) que l'application.
> Et c est la je pense que reside mon probleme: En fait, mon application
> est une "Application windows", et donc elle n utilise pas de dll. J ai
> cree la dll pour mon web service, mais mon appli ne l utilise pas.
>
>> Qu'entendez vous par "l'application en train de tourner"?
> En fait, j ai cree mon web service dans l espoir qu il me retourne la
> valeur d une variable de mon application. Cette variable est
> initialise a 100, puis est incrementee tout au long de l execution de
> mon appli.
Le mot espoir est particulièrement adapté dans ce cas :-)). Par quel
miracle voulez vous que les données de la DLL prennent comme par magie
les mêmes valeurs que les données correspondantes dans votre application
(exe)? Quelle relation peut-il exister entre les deux? Aucune. Il y a
effectivement un sérieux problème de design dans votre construction. La
bonne approche pourrait-être la suivante (je ne connais pas vos
contraintes donc j'avance au jugé):
- Votre application doit exposer un système de communication qui permet
à toute entité de code externe de l'interroger sur la valeur courante de
certaines données.
- Les méthodes de votre Web Service utilisent ce système pour interroger
l'appli quand cela est nécessaire.
Quant à ce système de communication, vous pouvez utiliser n'importe quel
mécanisme d'IPC qui conviendra le mieux à votre contexte:
- Objet singleton (à instance unique) qui contiendra les données en
question. L'objet (implémenté dans une DLL) expose des méthodes qui
permettent de positionner les valeurs (depuis l'appli) et de les lire
(depuis le Web Service). C'est ce qui ressemble le plus à ce que vous
essayez de faire. Voir par exemple
http://www.ondotnet.com/pub/a/dotnet/2002/11/11/singleton.html. Il y a
une seule instance de la DLL utilisée à la fois par l'application et le
Web Service.
- Fichier mappé en mémoire (Memory-mapped file - MMF) - qui me semble
adapté pour partager des données mais ce n'est pas une solution très
".Net".
- Sockets
- Pipe nommé
- Automation (vous faîtes de votre application un serveur COM exposant -
comme Excel ou Word - des méthodes qui retournent les valeurs en
question)
- Base de données (peut-être un peu lourd si il y a peu de données)
- Fichier partagé standard
- ...
Dans votre cas, les choses étant relativement simples, la première
solution est probablement la bonne.
> Il y a
effectivement un sérieux problème de design dans votre construction.
Ptlpn wrote:
>> Parce que le Web Service n'utilise visiblement pas la même instance
>> de la DLL (assembly) que l'application.
> Et c est la je pense que reside mon probleme: En fait, mon application
> est une "Application windows", et donc elle n utilise pas de dll. J ai
> cree la dll pour mon web service, mais mon appli ne l utilise pas.
>
>> Qu'entendez vous par "l'application en train de tourner"?
> En fait, j ai cree mon web service dans l espoir qu il me retourne la
> valeur d une variable de mon application. Cette variable est
> initialise a 100, puis est incrementee tout au long de l execution de
> mon appli.
Le mot espoir est particulièrement adapté dans ce cas :-)). Par quel
miracle voulez vous que les données de la DLL prennent comme par magie
les mêmes valeurs que les données correspondantes dans votre application
(exe)? Quelle relation peut-il exister entre les deux? Aucune. Il y a
effectivement un sérieux problème de design dans votre construction. La
bonne approche pourrait-être la suivante (je ne connais pas vos
contraintes donc j'avance au jugé):
- Votre application doit exposer un système de communication qui permet
à toute entité de code externe de l'interroger sur la valeur courante de
certaines données.
- Les méthodes de votre Web Service utilisent ce système pour interroger
l'appli quand cela est nécessaire.
Quant à ce système de communication, vous pouvez utiliser n'importe quel
mécanisme d'IPC qui conviendra le mieux à votre contexte:
- Objet singleton (à instance unique) qui contiendra les données en
question. L'objet (implémenté dans une DLL) expose des méthodes qui
permettent de positionner les valeurs (depuis l'appli) et de les lire
(depuis le Web Service). C'est ce qui ressemble le plus à ce que vous
essayez de faire. Voir par exemple
http://www.ondotnet.com/pub/a/dotnet/2002/11/11/singleton.html. Il y a
une seule instance de la DLL utilisée à la fois par l'application et le
Web Service.
- Fichier mappé en mémoire (Memory-mapped file - MMF) - qui me semble
adapté pour partager des données mais ce n'est pas une solution très
".Net".
- Sockets
- Pipe nommé
- Automation (vous faîtes de votre application un serveur COM exposant -
comme Excel ou Word - des méthodes qui retournent les valeurs en
question)
- Base de données (peut-être un peu lourd si il y a peu de données)
- Fichier partagé standard
- ...
Dans votre cas, les choses étant relativement simples, la première
solution est probablement la bonne.
