Je reviens avec cette question mais après avoir cherché :-)
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec VB.NET
je suis un peu perdu.
1: Je dois créer un serveur host pour recevoir l'appel du client sur le
serveur automation moi même ?
2: On m'a parlé de services serveur qui me permet de faire du remoting sans
hosting.
Bref, les différences me semblent Considérables.
3:Suis.je sur le bon chemin ?
4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
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
Guy DETIENNE
Salut ;O)
Il serait préférable de poser la question dans le groupe VB.NET
microsoft.public.fr.dotnet.vb
Guy
"**Pierre**" a écrit dans le message de news: elS%
Bonjour,
Je reviens avec cette question mais après avoir cherché :-)
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec VB.NET je suis un peu perdu. 1: Je dois créer un serveur host pour recevoir l'appel du client sur le serveur automation moi même ? 2: On m'a parlé de services serveur qui me permet de faire du remoting sans hosting.
Bref, les différences me semblent Considérables. 3:Suis.je sur le bon chemin ? 4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
D'avance merci de votre aide. Pierre
Salut ;O)
Il serait préférable de poser la question dans le groupe VB.NET
microsoft.public.fr.dotnet.vb
Guy
"**Pierre**" <pharmasoftsupprimerceci@tvs2net.ch> a écrit dans le message de
news: elS%230dHqEHA.1668@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je reviens avec cette question mais après avoir cherché :-)
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec
VB.NET
je suis un peu perdu.
1: Je dois créer un serveur host pour recevoir l'appel du client sur le
serveur automation moi même ?
2: On m'a parlé de services serveur qui me permet de faire du remoting
sans
hosting.
Bref, les différences me semblent Considérables.
3:Suis.je sur le bon chemin ?
4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
Il serait préférable de poser la question dans le groupe VB.NET
microsoft.public.fr.dotnet.vb
Guy
"**Pierre**" a écrit dans le message de news: elS%
Bonjour,
Je reviens avec cette question mais après avoir cherché :-)
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec VB.NET je suis un peu perdu. 1: Je dois créer un serveur host pour recevoir l'appel du client sur le serveur automation moi même ? 2: On m'a parlé de services serveur qui me permet de faire du remoting sans hosting.
Bref, les différences me semblent Considérables. 3:Suis.je sur le bon chemin ? 4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
D'avance merci de votre aide. Pierre
Patrick Philippot
**Pierre** wrote:
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec VB.NET je suis un peu perdu. 1: Je dois créer un serveur host pour recevoir l'appel du client sur le serveur automation moi même ? 2: On m'a parlé de services serveur qui me permet de faire du remoting sans hosting.
Bref, les différences me semblent Considérables. 3:Suis.je sur le bon chemin ? 4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
Bonjour Pierre,
Il faudrait que vous clarifiiez ce que vous voulez faire. Accéder un composant COM depuis un client .Net éloigné? Le contraire? Que veut dire "remoting sans hosting"? "Services serveurs"?
La philosophie .Net en matière de remoting est très différente de DCOM.
En COM / DCOM on privilégiait la tranparence. Un composant testé en local pouvait être déplacé physiquement sur un serveur sans que l'on ait à recompiler client ou serveur. C'était uniquement un problème de configuration.
En .Net (avec .Net Remoting), on privilégie la performance au détriment de la transparence (en gros). Pour activer un composant en remote, vous avez donc les choix suivants:
1. Utiliser .Net Remoting qui est donc moins transparent et un rien plus compliqué que DCOM (rien d'insurmontable cependant). Pas besoin d'infrastructure côté serveur. Le composant peut-être hébergé dans un EXE, voire un EXE tournant en tant que service Windows, ou bien sous COM+ (mais via Interop). Dans cette technologie, composant éloigné et client sont nécessairement .Net.
2. Vous évitez complètement l'utilisation de .Net Remoting et vous passez (plus simple) à une interface de type Web Service. Le client éloigné accède au composant via des appels aux méthodes d'un Web Service qui lui même instancie le composant. C'est la tendance lourde chez Microsoft et c'est vrai que c'est plus simple. Le choix .Net Remoting est plus adapté à un Intranet question performances. le choix Web Service est plus ouvert pour une utilisation sur Internet. Un Web Service .Net nécessite IIS sur le serveur.
3. Votre composant est écrit en .Net mais vous pouvez continuez à y accéder (depuis un client éloigné) comme un composant DCOM soit directement, soit au travers de COM+, en encapsulant ce composant par une couche Interop qui permet de voir ce composant .Net comme un composant COM. Dans cette hypothèse le client peut être non .Net ou .Net (dans ce dernier cas il utiliserait Interop pour voir l'objet éloigné comme un objet .Net - ce qu'il est d'ailleurs réellement - cette dernière solution est donc particulièrement peu efficace et totalement idiote :-) : si les 2 parties sont .Net, on fait du .Net Remoting).
4. Votre composant est non .Net (COM) et vous pouvez l'accéder depuis un client .Net comme décrit en 3.
Vous trouverez de nombreux "tutorials" sur .Net Remoting, par exemple là: http://www.developerfusion.com/show/1916/ http://www.csharphelp.com/archives2/archive421.html http://www.csharphelp.com/archives2/archive422.html http://www.csharphelp.com/archives2/archive423.html http://www.csharphelp.com/archives2/archive424.html http://www.c-sharpcorner.com/Tutorials/DnRemotingIntroDT001.asp (et bien sûr dans la doc Microsoft).
C'est du C# mais ça n'a pas d'importance, on utilise les mêmes objets en VB.
Je serai plus précis quand j'aurai eu vos éclaircissements.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
**Pierre** wrote:
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec
VB.NET je suis un peu perdu.
1: Je dois créer un serveur host pour recevoir l'appel du client sur
le serveur automation moi même ?
2: On m'a parlé de services serveur qui me permet de faire du
remoting sans hosting.
Bref, les différences me semblent Considérables.
3:Suis.je sur le bon chemin ?
4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
Bonjour Pierre,
Il faudrait que vous clarifiiez ce que vous voulez faire. Accéder un
composant COM depuis un client .Net éloigné? Le contraire? Que veut dire
"remoting sans hosting"? "Services serveurs"?
La philosophie .Net en matière de remoting est très différente de DCOM.
En COM / DCOM on privilégiait la tranparence. Un composant testé en
local pouvait être déplacé physiquement sur un serveur sans que l'on ait
à recompiler client ou serveur. C'était uniquement un problème de
configuration.
En .Net (avec .Net Remoting), on privilégie la performance au détriment
de la transparence (en gros). Pour activer un composant en remote, vous
avez donc les choix suivants:
1. Utiliser .Net Remoting qui est donc moins transparent et un rien plus
compliqué que DCOM (rien d'insurmontable cependant). Pas besoin
d'infrastructure côté serveur. Le composant peut-être hébergé dans un
EXE, voire un EXE tournant en tant que service Windows, ou bien sous
COM+ (mais via Interop). Dans cette technologie, composant éloigné et
client sont nécessairement .Net.
2. Vous évitez complètement l'utilisation de .Net Remoting et vous
passez (plus simple) à une interface de type Web Service. Le client
éloigné accède au composant via des appels aux méthodes d'un Web Service
qui lui même instancie le composant. C'est la tendance lourde chez
Microsoft et c'est vrai que c'est plus simple. Le choix .Net Remoting
est plus adapté à un Intranet question performances. le choix Web
Service est plus ouvert pour une utilisation sur Internet. Un Web
Service .Net nécessite IIS sur le serveur.
3. Votre composant est écrit en .Net mais vous pouvez continuez à y
accéder (depuis un client éloigné) comme un composant DCOM soit
directement, soit au travers de COM+, en encapsulant ce composant par
une couche Interop qui permet de voir ce composant .Net comme un
composant COM. Dans cette hypothèse le client peut être non .Net ou .Net
(dans ce dernier cas il utiliserait Interop pour voir l'objet éloigné
comme un objet .Net - ce qu'il est d'ailleurs réellement - cette
dernière solution est donc particulièrement peu efficace et totalement
idiote :-) : si les 2 parties sont .Net, on fait du .Net Remoting).
4. Votre composant est non .Net (COM) et vous pouvez l'accéder depuis un
client .Net comme décrit en 3.
Vous trouverez de nombreux "tutorials" sur .Net Remoting, par exemple
là:
http://www.developerfusion.com/show/1916/
http://www.csharphelp.com/archives2/archive421.html
http://www.csharphelp.com/archives2/archive422.html
http://www.csharphelp.com/archives2/archive423.html
http://www.csharphelp.com/archives2/archive424.html
http://www.c-sharpcorner.com/Tutorials/DnRemotingIntroDT001.asp
(et bien sûr dans la doc Microsoft).
C'est du C# mais ça n'a pas d'importance, on utilise les mêmes objets en
VB.
Je serai plus précis quand j'aurai eu vos éclaircissements.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec VB.NET je suis un peu perdu. 1: Je dois créer un serveur host pour recevoir l'appel du client sur le serveur automation moi même ? 2: On m'a parlé de services serveur qui me permet de faire du remoting sans hosting.
Bref, les différences me semblent Considérables. 3:Suis.je sur le bon chemin ? 4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
Bonjour Pierre,
Il faudrait que vous clarifiiez ce que vous voulez faire. Accéder un composant COM depuis un client .Net éloigné? Le contraire? Que veut dire "remoting sans hosting"? "Services serveurs"?
La philosophie .Net en matière de remoting est très différente de DCOM.
En COM / DCOM on privilégiait la tranparence. Un composant testé en local pouvait être déplacé physiquement sur un serveur sans que l'on ait à recompiler client ou serveur. C'était uniquement un problème de configuration.
En .Net (avec .Net Remoting), on privilégie la performance au détriment de la transparence (en gros). Pour activer un composant en remote, vous avez donc les choix suivants:
1. Utiliser .Net Remoting qui est donc moins transparent et un rien plus compliqué que DCOM (rien d'insurmontable cependant). Pas besoin d'infrastructure côté serveur. Le composant peut-être hébergé dans un EXE, voire un EXE tournant en tant que service Windows, ou bien sous COM+ (mais via Interop). Dans cette technologie, composant éloigné et client sont nécessairement .Net.
2. Vous évitez complètement l'utilisation de .Net Remoting et vous passez (plus simple) à une interface de type Web Service. Le client éloigné accède au composant via des appels aux méthodes d'un Web Service qui lui même instancie le composant. C'est la tendance lourde chez Microsoft et c'est vrai que c'est plus simple. Le choix .Net Remoting est plus adapté à un Intranet question performances. le choix Web Service est plus ouvert pour une utilisation sur Internet. Un Web Service .Net nécessite IIS sur le serveur.
3. Votre composant est écrit en .Net mais vous pouvez continuez à y accéder (depuis un client éloigné) comme un composant DCOM soit directement, soit au travers de COM+, en encapsulant ce composant par une couche Interop qui permet de voir ce composant .Net comme un composant COM. Dans cette hypothèse le client peut être non .Net ou .Net (dans ce dernier cas il utiliserait Interop pour voir l'objet éloigné comme un objet .Net - ce qu'il est d'ailleurs réellement - cette dernière solution est donc particulièrement peu efficace et totalement idiote :-) : si les 2 parties sont .Net, on fait du .Net Remoting).
4. Votre composant est non .Net (COM) et vous pouvez l'accéder depuis un client .Net comme décrit en 3.
Vous trouverez de nombreux "tutorials" sur .Net Remoting, par exemple là: http://www.developerfusion.com/show/1916/ http://www.csharphelp.com/archives2/archive421.html http://www.csharphelp.com/archives2/archive422.html http://www.csharphelp.com/archives2/archive423.html http://www.csharphelp.com/archives2/archive424.html http://www.c-sharpcorner.com/Tutorials/DnRemotingIntroDT001.asp (et bien sûr dans la doc Microsoft).
C'est du C# mais ça n'a pas d'importance, on utilise les mêmes objets en VB.
Je serai plus précis quand j'aurai eu vos éclaircissements.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
Guy DETIENNE wrote:
Il serait préférable de poser la question dans le groupe VB.NET
microsoft.public.fr.dotnet.vb
Oui. j'avais oublié où j'étais :-) . Quoique nous n'avons pas encore déterminé s'il s'agit d'un problème de mixité .Net / DCOM ou pas.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Guy DETIENNE wrote:
Il serait préférable de poser la question dans le groupe VB.NET
microsoft.public.fr.dotnet.vb
Oui. j'avais oublié où j'étais :-) . Quoique nous n'avons pas encore
déterminé s'il s'agit d'un problème de mixité .Net / DCOM ou pas.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Il serait préférable de poser la question dans le groupe VB.NET
microsoft.public.fr.dotnet.vb
Oui. j'avais oublié où j'étais :-) . Quoique nous n'avons pas encore déterminé s'il s'agit d'un problème de mixité .Net / DCOM ou pas.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
**Pierre**
Pardon faux news group
"**Pierre**" a écrit dans le message de news: elS#
Bonjour,
Je reviens avec cette question mais après avoir cherché :-)
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec
VB.NET
je suis un peu perdu. 1: Je dois créer un serveur host pour recevoir l'appel du client sur le serveur automation moi même ? 2: On m'a parlé de services serveur qui me permet de faire du remoting
sans
hosting.
Bref, les différences me semblent Considérables. 3:Suis.je sur le bon chemin ? 4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
D'avance merci de votre aide. Pierre
Pardon faux news group
"**Pierre**" <pharmasoftsupprimerceci@tvs2net.ch> a écrit dans le message de
news: elS#0dHqEHA.1668@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je reviens avec cette question mais après avoir cherché :-)
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec
VB.NET
je suis un peu perdu.
1: Je dois créer un serveur host pour recevoir l'appel du client sur le
serveur automation moi même ?
2: On m'a parlé de services serveur qui me permet de faire du remoting
sans
hosting.
Bref, les différences me semblent Considérables.
3:Suis.je sur le bon chemin ?
4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
"**Pierre**" a écrit dans le message de news: elS#
Bonjour,
Je reviens avec cette question mais après avoir cherché :-)
Avec VB6, j'utilisais ActiveX et Automation Manager ou Dcom mais avec
VB.NET
je suis un peu perdu. 1: Je dois créer un serveur host pour recevoir l'appel du client sur le serveur automation moi même ? 2: On m'a parlé de services serveur qui me permet de faire du remoting
sans
hosting.
Bref, les différences me semblent Considérables. 3:Suis.je sur le bon chemin ? 4: Pourquoi a t'on abandonné le service DCOM qui me semblait simple ?
