Discussion :

[Tetram165]

Bonjour à tous,

Dans le cadre d'une application developpée, j'ai besoin d'avoir des données, classe ou librairie, ou n'importe quoi d'autre (mais pas en COM) qui permettrait de communiquer entre plusieurs applis. Dans ce cas-ci, il faudrait qu'un programme charge une classe (même en statique, ca n'a aucune importance), et que celle-ci soit disponible par d'autre programme (par exemple, un premier programme initialise une string en static, et une deuxième appli vient lire le contenu de cette string, donc dans deux process différents, voir deux comptes différents (dans le cadre de services windows))...
En vb6, je pense que cela ressemble aux exe activeX, mais est-il possible d'effectuer la même chose avec DotNet?


D'avance je vous remercie...

[Bluedeep]

Ben, un service qui expose des objets via .Net Remoting. (ou mieux WCF, si tu peux déployer le fw 3.0).

Ca marche bien mieux que les ActiveX out-process.

[Tetram165]

Ok pour le .NET Remoting mais n'existe t-il pas une solution n'utilisant pas le Remoting???

EDIT : Je viens de prendre connaissance de l'existance d'"Assembly Domain neutral", qui correspondrait à ce que je recherche, a ceci près qu'il faudrait que l'assembly ne soit pas dans la GAC...

bReF :

[Bluedeep]

Ok pour le .NET Remoting mais n'existe t-il pas une solution n'utilisant pas le Remoting???

Si, certainement, tu peux utiliser la panoplie complète des IPC de Windows :

- Named Pipe
- Message Queue
- RPC
- Mémoire partagée

T'as le choix; tu fais comme tu veux.

[Tetram165]

Mémoire partagée

Concernant, cette option peux-tu m'informer un plus dessus? genre la mise en place, ou uniquement des points de recherche pour rebondir...

D'avance un grand merci

[Bluedeep]

Concernant, cette option peux-tu m'informer un plus dessus? genre la mise en place, ou uniquement des points de recherche pour rebondir...

D'avance un grand merci

Je vais avoir un peu de mal ... car c'est la seule technique d'IPC que je n'utilise jamais. (d'une maniére général je n'aime pas utiliser un IPC exclusivement local : on ne sait jamais comment évolue une appli).

Ceci dit, cherche dans MSDN avec IPC & File Mapping.

Mais dans la mesure où il semble que tu veuilles faire causer un process .Net avec un autre process .net, je comprends mal pourquoi tu veux te compliquer la vie en utilisant autre chose que le Remoting.

[SaumonAgile]

Concernant, cette option peux-tu m'informer un plus dessus? genre la mise en place, ou uniquement des points de recherche pour rebondir...

D'avance un grand merci

En gros, il s'agit de partager une zone mémoire spécifique entre deux applications. Mais c'est comme quand tu gribouilles avec un copain sur la même feuille, il faut faire attention de ne pas s'emméler les crayons.

[Graffito]

une solution n'utilisant pas le Remoting

Client and server sockets ?
http://stephaneey.developpez.com/tut...otnet/sockets/

[Bluedeep]

Ah, j'ai oublié quelques formes sd'IPC dans mon inventaire à la Prevert :

- MailSlots (qui l'a utilisé ? moi, personnellement jamais)
- Sockets
- Data Copy (via VM_COPYDATA - jamais utilisé pour ma part).
- Presse-papier

et pour mémoire :

- COM
- DDE (p...n; ca me rajeunit pas, mais je crois que ça existe toujours).

[Tetram165]

Je vous remercie tous pour vos contributions... Apparement on se dirigerait vers une solution remoting, reste encore des problèmes au niveaux des events... à voir dans mon nouveau post !

En fait pour ce post, j'aimerais aussi connaitre une technique permettrait d'être aussi performante que les events, parce que, apparement en remoting, c est un peu la gadoue pour la gestion des events à travers d'objets distants...

[theMonz31]

salut

disons que tu ne geres pas les event "simplement" en Remoting...

Il faut passer par les SinkMessage (je dis cela de mémoire)... car en faite,
le serveur doit connaitre une classe du client pour l'appeler...

S'abonner à l'event d'un objet ne marche pas sinon...

The Monz, Toulouse

[Bluedeep]

Sinon, utiliser WCF avec l'élégant "DuplexContract", et plus de problèmes d'event.