J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET
qui pilote Excel).
Existe-il un moyen de récupérer une instance d'une classe d'une autre
application .NET ?
Pour information, je peux modifier les codes sources de mes 2
applications si nécessaire...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier
Bonjour,
Les technologies COM devraient répondre au problème. Il faudra modifier les 2 codes sources. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/ht ml/vcwlkCOMInteropPart1CClientTutorial.asp
Olivier
On 24 jan, 11:49, Gilles TOURREAU wrote:
Bonjour,
J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET qui pilote Excel).
Existe-il un moyen de récupérer une instance d'une classe d'une autre application .NET ? Pour information, je peux modifier les codes sources de mes 2 applications si nécessaire...
En vous remerciant par avance de vos lumières !
Cordialement
-- Gilles TOURREAU Responsable Informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans !http://www.pos.fr
Bonjour,
Les technologies COM devraient répondre au problème. Il faudra
modifier les 2 codes sources.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/ht ml/vcwlkCOMInteropPart1CClientTutorial.asp
Olivier
On 24 jan, 11:49, Gilles TOURREAU <gilles.tourr...@pos.fr> wrote:
Bonjour,
J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET
qui pilote Excel).
Existe-il un moyen de récupérer une instance d'une classe d'une autre
application .NET ?
Pour information, je peux modifier les codes sources de mes 2
applications si nécessaire...
Les technologies COM devraient répondre au problème. Il faudra modifier les 2 codes sources. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/ht ml/vcwlkCOMInteropPart1CClientTutorial.asp
Olivier
On 24 jan, 11:49, Gilles TOURREAU wrote:
Bonjour,
J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET qui pilote Excel).
Existe-il un moyen de récupérer une instance d'une classe d'une autre application .NET ? Pour information, je peux modifier les codes sources de mes 2 applications si nécessaire...
En vous remerciant par avance de vos lumières !
Cordialement
-- Gilles TOURREAU Responsable Informatique
Société P.O.S Spécialiste en motoculture depuis + de 30 ans !http://www.pos.fr
Patrick Philippot
Gilles TOURREAU wrote:
J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET qui pilote Excel).
Existe-il un moyen de récupérer une instance d'une classe d'une autre application .NET ?
L'utilisation de COM n'est pas dans la philosophie .Net et devrait être évitée sauf contrainte forte. Là où l'on parlait de COM dans le monde Win32, on parle de .Net Remoting dans le monde .Net, voire de Web Services. Le choix entre Web Services et .Net Remoting dépend de nombreux critères mais pour une communication en local entre 2 applications, .Net Remoting fait parfaitement l'affaire.
Vous pouvez également utiliser pour la communication entre les 2 applis, les mécanismes d'IPC habituels: sockets, pipes,... Mais pour parler d'objet à objet, .Net Remoting est mieux adapté.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Gilles TOURREAU wrote:
J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET
qui pilote Excel).
Existe-il un moyen de récupérer une instance d'une classe d'une autre
application .NET ?
L'utilisation de COM n'est pas dans la philosophie .Net et devrait être
évitée sauf contrainte forte. Là où l'on parlait de COM dans le monde Win32,
on parle de .Net Remoting dans le monde .Net, voire de Web Services. Le
choix entre Web Services et .Net Remoting dépend de nombreux critères mais
pour une communication en local entre 2 applications, .Net Remoting fait
parfaitement l'affaire.
Vous pouvez également utiliser pour la communication entre les 2 applis, les
mécanismes d'IPC habituels: sockets, pipes,... Mais pour parler d'objet à
objet, .Net Remoting est mieux adapté.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET qui pilote Excel).
Existe-il un moyen de récupérer une instance d'une classe d'une autre application .NET ?
L'utilisation de COM n'est pas dans la philosophie .Net et devrait être évitée sauf contrainte forte. Là où l'on parlait de COM dans le monde Win32, on parle de .Net Remoting dans le monde .Net, voire de Web Services. Le choix entre Web Services et .Net Remoting dépend de nombreux critères mais pour une communication en local entre 2 applications, .Net Remoting fait parfaitement l'affaire.
Vous pouvez également utiliser pour la communication entre les 2 applis, les mécanismes d'IPC habituels: sockets, pipes,... Mais pour parler d'objet à objet, .Net Remoting est mieux adapté.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Merlin
> J'ai 2 applications que j'ai réalisé en .NET (App1 et App2). Je voudrais piloter App1 via App2 (Un peu comme une application .NET qui pilote Excel).
il faut faire du Remoting puisque les deux applis sont .Net c'est le plus naturel. Si le pilotage doit pouvoir se faire aussi depuis des softs non .net il faut alors préférer la technique des web service.
Maintenant il existe aussi des tas d'autres possibilités comme utiliser les named pipes, ou une liaison tcp/ip.
--
///3rL1n____
> J'ai 2 applications que j'ai réalisé en .NET (App1 et App2).
Je voudrais piloter App1 via App2 (Un peu comme une application .NET qui
pilote Excel).
il faut faire du Remoting puisque les deux applis sont .Net c'est le
plus naturel. Si le pilotage doit pouvoir se faire aussi depuis des
softs non .net il faut alors préférer la technique des web service.
Maintenant il existe aussi des tas d'autres possibilités comme utiliser
les named pipes, ou une liaison tcp/ip.
> J'ai 2 applications que j'ai réalisé en .NET (App1 et App2). Je voudrais piloter App1 via App2 (Un peu comme une application .NET qui pilote Excel).
il faut faire du Remoting puisque les deux applis sont .Net c'est le plus naturel. Si le pilotage doit pouvoir se faire aussi depuis des softs non .net il faut alors préférer la technique des web service.
Maintenant il existe aussi des tas d'autres possibilités comme utiliser les named pipes, ou une liaison tcp/ip.
--
///3rL1n____
Michael Moreno
La technologie Remoting mentionnee permet cela mais elle a les manques suivants par rapport a COM : - Sous DCOM si le second exe n'est pas lance, la creation d'un objet lancera automatiquement l'exe. C'est tres pratique. La il va falloir gerer le cas de qui lance l'exe, si c'est toi il faudra connaitre le chemin de ce fichu exe, etc. - sous DCOM la gestion des identites, cest a dire sous quel compte est lance l'exe, est plus simple pour le cas mentionnee. - sous DCOM on s'emmerde pas la vie si un port TCP/IP est deja pris par une autre appli. Je sais qu'on peut mettre cela dans un fichier config mais en pratique les fichiers config c'est vite la pagaille et on finit par quasiment tout foutre dans une base de donnees => plus de dev. Le choix d'une channel IPC est a envisager mais cela veut dire qu'il faut absolument que les 2 exes soient toujours sur la meme machine. - C'est infiniment plus lent que COM. - + divers problemes que tu trouveras tres vite.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
La technologie Remoting mentionnee permet cela mais elle a les manques
suivants par rapport a COM :
- Sous DCOM si le second exe n'est pas lance, la creation d'un objet
lancera automatiquement l'exe. C'est tres pratique. La il va falloir
gerer le cas de qui lance l'exe, si c'est toi il faudra connaitre le
chemin de ce fichu exe, etc.
- sous DCOM la gestion des identites, cest a dire sous quel compte est
lance l'exe, est plus simple pour le cas mentionnee.
- sous DCOM on s'emmerde pas la vie si un port TCP/IP est deja pris par
une autre appli. Je sais qu'on peut mettre cela dans un fichier config
mais en pratique les fichiers config c'est vite la pagaille et on finit
par quasiment tout foutre dans une base de donnees => plus de dev. Le
choix d'une channel IPC est a envisager mais cela veut dire qu'il faut
absolument que les 2 exes soient toujours sur la meme machine.
- C'est infiniment plus lent que COM.
- + divers problemes que tu trouveras tres vite.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
La technologie Remoting mentionnee permet cela mais elle a les manques suivants par rapport a COM : - Sous DCOM si le second exe n'est pas lance, la creation d'un objet lancera automatiquement l'exe. C'est tres pratique. La il va falloir gerer le cas de qui lance l'exe, si c'est toi il faudra connaitre le chemin de ce fichu exe, etc. - sous DCOM la gestion des identites, cest a dire sous quel compte est lance l'exe, est plus simple pour le cas mentionnee. - sous DCOM on s'emmerde pas la vie si un port TCP/IP est deja pris par une autre appli. Je sais qu'on peut mettre cela dans un fichier config mais en pratique les fichiers config c'est vite la pagaille et on finit par quasiment tout foutre dans une base de donnees => plus de dev. Le choix d'une channel IPC est a envisager mais cela veut dire qu'il faut absolument que les 2 exes soient toujours sur la meme machine. - C'est infiniment plus lent que COM. - + divers problemes que tu trouveras tres vite.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Gilles TOURREAU
Le Mon, 29 Jan 2007 10:47:44 +0100, Michael Moreno a écrit:
La technologie Remoting mentionnee permet cela mais elle a les manques suivants par rapport a COM : - Sous DCOM si le second exe n'est pas lance, la creation d'un objet lancera automatiquement l'exe. C'est tres pratique. La il va falloir gerer le cas de qui lance l'exe, si c'est toi il faudra connaitre le chemin de ce fichu exe, etc. - sous DCOM la gestion des identites, cest a dire sous quel compte est lance l'exe, est plus simple pour le cas mentionnee. - sous DCOM on s'emmerde pas la vie si un port TCP/IP est deja pris par une autre appli. Je sais qu'on peut mettre cela dans un fichier config mais en pratique les fichiers config c'est vite la pagaille et on finit par quasiment tout foutre dans une base de donnees => plus de dev. Le choix d'une channel IPC est a envisager mais cela veut dire qu'il faut absolument que les 2 exes soient toujours sur la meme machine. - C'est infiniment plus lent que COM. - + divers problemes que tu trouveras tres vite.
Je vous remercie pour votre réponse (ainsi que pour les autres réponses des autres personnes)... Mais en fait je cherche quelque de très simple :
J'ai 2 applications .NET (En Forms pour être précis) qui sont executés en local. Il n'y aura pas de communication entre ces 2 applications via un réseau quelconque...
L'application App1 se lance et créer une instance de la classe "App1Class".
L'application App2 se lance : - Essaye de voir si l'application App1 est lancé (si pas lancé, message d'insulte à l'utilisateur) - Récupère l'instance App1Class qui a été crée par App1 - Utilise les méthodes public de App1Class...
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation supplémentaire (sérialiser des objets...etc)
Par contre (là je n'y connais pas grand chose) le COM ne nécessite pas aussi de "formater" les méthodes de façon à ce qu'elle puisse être appellé depuis n'importe quel autre type d'application ? Ne faut'il pas en plus ajouter "un proxy" pour appeler ce service ?
En vous remerciant par avance de vos lumières...
Cordialement
-- Gilles TOURREAU Responsable Informatique
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Le Mon, 29 Jan 2007 10:47:44 +0100, Michael Moreno
<MyFirstName.MySurname@free.fr> a écrit:
La technologie Remoting mentionnee permet cela mais elle a les manques
suivants par rapport a COM :
- Sous DCOM si le second exe n'est pas lance, la creation d'un objet
lancera automatiquement l'exe. C'est tres pratique. La il va falloir
gerer le cas de qui lance l'exe, si c'est toi il faudra connaitre le
chemin de ce fichu exe, etc.
- sous DCOM la gestion des identites, cest a dire sous quel compte est
lance l'exe, est plus simple pour le cas mentionnee.
- sous DCOM on s'emmerde pas la vie si un port TCP/IP est deja pris par
une autre appli. Je sais qu'on peut mettre cela dans un fichier config
mais en pratique les fichiers config c'est vite la pagaille et on finit
par quasiment tout foutre dans une base de donnees => plus de dev. Le
choix d'une channel IPC est a envisager mais cela veut dire qu'il faut
absolument que les 2 exes soient toujours sur la meme machine.
- C'est infiniment plus lent que COM.
- + divers problemes que tu trouveras tres vite.
Je vous remercie pour votre réponse (ainsi que pour les autres réponses
des autres personnes)...
Mais en fait je cherche quelque de très simple :
J'ai 2 applications .NET (En Forms pour être précis) qui sont executés en
local.
Il n'y aura pas de communication entre ces 2 applications via un réseau
quelconque...
L'application App1 se lance et créer une instance de la classe "App1Class".
L'application App2 se lance :
- Essaye de voir si l'application App1 est lancé (si pas lancé, message
d'insulte à l'utilisateur)
- Récupère l'instance App1Class qui a été crée par App1
- Utilise les méthodes public de App1Class...
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation
supplémentaire (sérialiser des objets...etc)
Par contre (là je n'y connais pas grand chose) le COM ne nécessite pas
aussi de "formater" les méthodes de façon à ce qu'elle puisse être appellé
depuis n'importe quel autre type d'application ? Ne faut'il pas en plus
ajouter "un proxy" pour appeler ce service ?
Le Mon, 29 Jan 2007 10:47:44 +0100, Michael Moreno a écrit:
La technologie Remoting mentionnee permet cela mais elle a les manques suivants par rapport a COM : - Sous DCOM si le second exe n'est pas lance, la creation d'un objet lancera automatiquement l'exe. C'est tres pratique. La il va falloir gerer le cas de qui lance l'exe, si c'est toi il faudra connaitre le chemin de ce fichu exe, etc. - sous DCOM la gestion des identites, cest a dire sous quel compte est lance l'exe, est plus simple pour le cas mentionnee. - sous DCOM on s'emmerde pas la vie si un port TCP/IP est deja pris par une autre appli. Je sais qu'on peut mettre cela dans un fichier config mais en pratique les fichiers config c'est vite la pagaille et on finit par quasiment tout foutre dans une base de donnees => plus de dev. Le choix d'une channel IPC est a envisager mais cela veut dire qu'il faut absolument que les 2 exes soient toujours sur la meme machine. - C'est infiniment plus lent que COM. - + divers problemes que tu trouveras tres vite.
Je vous remercie pour votre réponse (ainsi que pour les autres réponses des autres personnes)... Mais en fait je cherche quelque de très simple :
J'ai 2 applications .NET (En Forms pour être précis) qui sont executés en local. Il n'y aura pas de communication entre ces 2 applications via un réseau quelconque...
L'application App1 se lance et créer une instance de la classe "App1Class".
L'application App2 se lance : - Essaye de voir si l'application App1 est lancé (si pas lancé, message d'insulte à l'utilisateur) - Récupère l'instance App1Class qui a été crée par App1 - Utilise les méthodes public de App1Class...
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation supplémentaire (sérialiser des objets...etc)
Par contre (là je n'y connais pas grand chose) le COM ne nécessite pas aussi de "formater" les méthodes de façon à ce qu'elle puisse être appellé depuis n'importe quel autre type d'application ? Ne faut'il pas en plus ajouter "un proxy" pour appeler ce service ?
En vous remerciant par avance de vos lumières...
Cordialement
-- Gilles TOURREAU Responsable Informatique
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Michael Moreno
> L'application App1 se lance et créer une instance de la classe "App1Class".
ok.
L'application App2 se lance : - Essaye de voir si l'application App1 est lancé (si pas lancé, message d'insulte à l'utilisateur)
Ca c'est pas si simple que cela en a l'air. C'est faisable mais y a tout un tas de problemes possibles : - securite - nom de l'appli tronquee a environ 20 char sous les versions de windows < XP lorsqu'on les recupere - probleme du multi-utilisateur - etc
- Récupère l'instance App1Class qui a été crée par App1 - Utilise les méthodes public de App1Class...
.Net Remoting fait cela tres bien. Il vaut mieux passer par une interface toutefois.
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation supplémentaire (sérialiser des objets...etc)
Remoting est effectivement un niveau plus bas que COM mais faire du DCOM avec une appli exe C# est assez difficile. Dans le cas present, je pense que Remoting convient bien.
MSMQ offre aussi pas mal de possibilites et permet de decoupler totalement les 2 applis ce qui peut etre tres utile.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
> L'application App1 se lance et créer une instance de la classe "App1Class".
ok.
L'application App2 se lance :
- Essaye de voir si l'application App1 est lancé (si pas lancé, message
d'insulte à l'utilisateur)
Ca c'est pas si simple que cela en a l'air.
C'est faisable mais y a tout un tas de problemes possibles :
- securite
- nom de l'appli tronquee a environ 20 char sous les versions de
windows < XP lorsqu'on les recupere
- probleme du multi-utilisateur
- etc
- Récupère l'instance App1Class qui a été crée par App1
- Utilise les méthodes public de App1Class...
.Net Remoting fait cela tres bien. Il vaut mieux passer par une
interface toutefois.
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation
supplémentaire (sérialiser des objets...etc)
Remoting est effectivement un niveau plus bas que COM mais faire du
DCOM avec une appli exe C# est assez difficile. Dans le cas present, je
pense que Remoting convient bien.
MSMQ offre aussi pas mal de possibilites et permet de decoupler
totalement les 2 applis ce qui peut etre tres utile.
--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/
> L'application App1 se lance et créer une instance de la classe "App1Class".
ok.
L'application App2 se lance : - Essaye de voir si l'application App1 est lancé (si pas lancé, message d'insulte à l'utilisateur)
Ca c'est pas si simple que cela en a l'air. C'est faisable mais y a tout un tas de problemes possibles : - securite - nom de l'appli tronquee a environ 20 char sous les versions de windows < XP lorsqu'on les recupere - probleme du multi-utilisateur - etc
- Récupère l'instance App1Class qui a été crée par App1 - Utilise les méthodes public de App1Class...
.Net Remoting fait cela tres bien. Il vaut mieux passer par une interface toutefois.
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation supplémentaire (sérialiser des objets...etc)
Remoting est effectivement un niveau plus bas que COM mais faire du DCOM avec une appli exe C# est assez difficile. Dans le cas present, je pense que Remoting convient bien.
MSMQ offre aussi pas mal de possibilites et permet de decoupler totalement les 2 applis ce qui peut etre tres utile.
-- Michael ---- http://michael.moreno.free.fr/ http://port.cogolin.free.fr/
Gilles TOURREAU
Le Mon, 29 Jan 2007 15:25:42 +0100, Michael Moreno a écrit:
L'application App1 se lance et créer une instance de la classe "App1Class".
ok.
L'application App2 se lance : - Essaye de voir si l'application App1 est lancé (si pas lancé, message d'insulte à l'utilisateur)
Ca c'est pas si simple que cela en a l'air. C'est faisable mais y a tout un tas de problemes possibles : - securite - nom de l'appli tronquee a environ 20 char sous les versions de windows < XP lorsqu'on les recupere - probleme du multi-utilisateur - etc
- Récupère l'instance App1Class qui a été crée par App1 - Utilise les méthodes public de App1Class...
..Net Remoting fait cela tres bien. Il vaut mieux passer par une interface toutefois.
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation supplémentaire (sérialiser des objets...etc)
Remoting est effectivement un niveau plus bas que COM mais faire du DCOM avec une appli exe C# est assez difficile. Dans le cas present, je pense que Remoting convient bien.
MSMQ offre aussi pas mal de possibilites et permet de decoupler totalement les 2 applis ce qui peut etre tres utile.
Mais le Remoting, nécessite que toutes les classes qui circulent entre les applications soient sérialisables ?
Juste par curiosité : Le Remoting peut-il être utilisé via des applications autre que .NET (ex : MFC/VB6) ?
Cordialement
-- Gilles TOURREAU Responsable Informatique
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Le Mon, 29 Jan 2007 15:25:42 +0100, Michael Moreno
<MyFirstName.MySurname@free.fr> a écrit:
L'application App1 se lance et créer une instance de la classe
"App1Class".
ok.
L'application App2 se lance :
- Essaye de voir si l'application App1 est lancé (si pas lancé, message
d'insulte à l'utilisateur)
Ca c'est pas si simple que cela en a l'air.
C'est faisable mais y a tout un tas de problemes possibles :
- securite
- nom de l'appli tronquee a environ 20 char sous les versions de windows
< XP lorsqu'on les recupere
- probleme du multi-utilisateur
- etc
- Récupère l'instance App1Class qui a été crée par App1
- Utilise les méthodes public de App1Class...
..Net Remoting fait cela tres bien. Il vaut mieux passer par une
interface toutefois.
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation
supplémentaire (sérialiser des objets...etc)
Remoting est effectivement un niveau plus bas que COM mais faire du DCOM
avec une appli exe C# est assez difficile. Dans le cas present, je pense
que Remoting convient bien.
MSMQ offre aussi pas mal de possibilites et permet de decoupler
totalement les 2 applis ce qui peut etre tres utile.
Mais le Remoting, nécessite que toutes les classes qui circulent entre les
applications soient sérialisables ?
Juste par curiosité : Le Remoting peut-il être utilisé via des
applications autre que .NET (ex : MFC/VB6) ?
Le Mon, 29 Jan 2007 15:25:42 +0100, Michael Moreno a écrit:
L'application App1 se lance et créer une instance de la classe "App1Class".
ok.
L'application App2 se lance : - Essaye de voir si l'application App1 est lancé (si pas lancé, message d'insulte à l'utilisateur)
Ca c'est pas si simple que cela en a l'air. C'est faisable mais y a tout un tas de problemes possibles : - securite - nom de l'appli tronquee a environ 20 char sous les versions de windows < XP lorsqu'on les recupere - probleme du multi-utilisateur - etc
- Récupère l'instance App1Class qui a été crée par App1 - Utilise les méthodes public de App1Class...
..Net Remoting fait cela tres bien. Il vaut mieux passer par une interface toutefois.
Je cherche juste à faire ceci...
Je trouve que Remoting et le WebService demande trop de programmation supplémentaire (sérialiser des objets...etc)
Remoting est effectivement un niveau plus bas que COM mais faire du DCOM avec une appli exe C# est assez difficile. Dans le cas present, je pense que Remoting convient bien.
MSMQ offre aussi pas mal de possibilites et permet de decoupler totalement les 2 applis ce qui peut etre tres utile.
Mais le Remoting, nécessite que toutes les classes qui circulent entre les applications soient sérialisables ?
Juste par curiosité : Le Remoting peut-il être utilisé via des applications autre que .NET (ex : MFC/VB6) ?
Cordialement
-- Gilles TOURREAU Responsable Informatique
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Patrick Philippot
Gilles TOURREAU wrote:
Juste par curiosité : Le Remoting peut-il être utilisé via des applications autre que .NET (ex : MFC/VB6) ?
Non. .Net Remoting nécessite .Net à chaque bout du tuyau.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Gilles TOURREAU wrote:
Juste par curiosité : Le Remoting peut-il être utilisé via des
applications autre que .NET (ex : MFC/VB6) ?
Non. .Net Remoting nécessite .Net à chaque bout du tuyau.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
> Mais le Remoting, nécessite que toutes les classes qui circulent entre les applications soient sérialisables ?
S'il faut envoyer ces classes d'une appli vers une autre alors il faut forcement les serialiser.
Juste par curiosité : Le Remoting peut-il être utilisé via des applications autre que .NET (ex : MFC/VB6) ?
Non. MSMQ permet cela, la serialization se faisant dans ce cas a la main au travers d'un ADO Recordset le plus souvent.
--
----------------------------------------------
http://michael.moreno.free.fr/
Merlin
> Mais le Remoting, nécessite que toutes les classes qui circulent entre les applications soient sérialisables ?
les instances qui traversent le remoting sont par force sérialisables oui. Mais sous Remoting il y a aussi la possibilité d'utiliser des interfaces plutôt que des objets et cela peut simplifier les choses (et rendre les applis plus facilement maintenable).
Juste par curiosité : Le Remoting peut-il être utilisé via des applications autre que .NET (ex : MFC/VB6) ?
non, forcément .NET des deux côtés de la communication. Quand on doit s'ouvrir à d'autres possibilités on utilise alors plutôt les services web.
--
///3rL1n____
> Mais le Remoting, nécessite que toutes les classes qui circulent entre les
applications soient sérialisables ?
les instances qui traversent le remoting sont par force sérialisables
oui. Mais sous Remoting il y a aussi la possibilité d'utiliser des
interfaces plutôt que des objets et cela peut simplifier les choses (et
rendre les applis plus facilement maintenable).
Juste par curiosité : Le Remoting peut-il être utilisé via des applications
autre que .NET (ex : MFC/VB6) ?
non, forcément .NET des deux côtés de la communication. Quand on doit
s'ouvrir à d'autres possibilités on utilise alors plutôt les services
web.
> Mais le Remoting, nécessite que toutes les classes qui circulent entre les applications soient sérialisables ?
les instances qui traversent le remoting sont par force sérialisables oui. Mais sous Remoting il y a aussi la possibilité d'utiliser des interfaces plutôt que des objets et cela peut simplifier les choses (et rendre les applis plus facilement maintenable).
Juste par curiosité : Le Remoting peut-il être utilisé via des applications autre que .NET (ex : MFC/VB6) ?
non, forcément .NET des deux côtés de la communication. Quand on doit s'ouvrir à d'autres possibilités on utilise alors plutôt les services web.
