Net Remote

[Je reposte donc ici]

*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
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr


begin 666 smile.gif
M1TE&.#EA#P`/`)$!`````+^_O___`````"'Y! $```$`+ `````/`````(N
MC V9QY$"X6(@6GGJO0!)+3RA$XDA:&Y6JGXMIX$K%G,8^2EE]G:4?&ID%+Y#
#`0`[
`
end

Bonjour et merci de votre réponse.

J'utilise le Dcom actuellement pour partager une/des imprimantes sériels sur
un réseaux et aussi un
lecteur de carte de crédit (sériel). Le travail est réalisé à l'aide
d'activeX et automation manager.

A l'avenir, je veux aussi pouvoir faire des application dont certains
composants résident sur le serveur pour l'accès aux données (access ou SQL
server). Dans ce cadre, j'ai déjà eu la réponse suivante mais je n'ai pas
encore résolu le problème :

<<Avant de te lancer dans le remoting, tu peux également utiliser, les
Composants dit EnterpriseServer.
En gros ce sont des composants .NET qui pourront s'installer sur le serveur
d'application Windows (COM+ disponible en standard sur nos servers) ainsi tu
pourras profiter de tous les avantages. (Pooling d'objet, transaction
Distribuées, etc....
En utilisant ce serveur d'application, tu t'évites de développer toi même le
serveur qui hostera ton composant.>>

Voila, merci de votre aide

Pierre



"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message
de news: esxIucJqEHA.556@tk2msftngp13.phx.gbl...

[Je reposte donc ici]

*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
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

**Pierre** wrote:

A l'avenir, je veux aussi pouvoir faire des application dont certains
composants résident sur le serveur pour l'accès aux données (access
ou SQL server). Dans ce cadre, j'ai déjà eu la réponse suivante mais
je n'ai pas encore résolu le problème :

<<Avant de te lancer dans le remoting, tu peux également utiliser, les
Composants dit EnterpriseServer.
En gros ce sont des composants .NET qui pourront s'installer sur le
serveur d'application Windows (COM+ disponible en standard sur nos
servers) ainsi tu pourras profiter de tous les avantages. (Pooling
d'objet, transaction Distribuées, etc....
En utilisant ce serveur d'application, tu t'évites de développer toi
même le serveur qui hostera ton composant.>>

Votre interlocuteur voulait sans doute parler du namespace
System.EnterpriseServices et de la classe ServicedComponent. Tout
composant .Net dérivé de cette classe est installable sous COM+ car il
sera vu comme un composant COM (voir la doc sur ce sujet). Une fois
installé sous COM+, ce composant sera utilisable par tout client
éloigné, .Net ou COM. Mais si le client est .Net, il vaut mieux utiliser
ce composant via .Net Remoting comme je l'ai déjà expliqué.

Si vous prévoyez que les composants en question seront utilisés à la
fois par des clients .Net et COM, la stratégie suivante est
envisageable:

1. Développez un composant .Net qui sera directement accessible via .Net
Remoting (pour les clients .Net).

2. Développez une classe dérivée de ServicedComponent qui déléguera ces
traitements au composant .Net cité en (1). Ce sera juste un front-end
qui ne fera qu'appeler les méthodes du composant principal. Installez ce
composant sous COM+.

3. De cette manière les clients auront le choix entre 2 canaux
d'activation qui se référeront en final au même code.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Bonjour et encore merci de la réponse,

Ca se clarifie petit à petit mais j'ai pas encore la solution finale

Pour faire du remoting, je peux soit

A: Utiliser un service Web

B: Faire du Net. Remoting avec une DLL .NET et l'encapsuler dans un EXE qui
me sert de Host sur le serveur. Le mettre dans un service Windows ou lancer
l'exe hosting avant d'appeler mon objet. Juste ?

C: Faire du DCOM même avec une DLL .NET. Même si c'est idiot, j'aimerai,
pour bien pour comprendre, tester cette méthode et je ne trouve pas comment
faire. Auriez-vous un exemple. Dans les docs, j'ai vu que l'ancien projet
ActiveX.exe de VB6 se faisait avec un composant .NET sous VB.NET mais je
pense que celà suppose du NET Remoting. Je reviens donc sur ma question :
comment faire d'un projet .NET un activeX.exe visible sous Dcom ? J'ai
essayé avec une classe dérivée de <System.EnterpriseServices> mais
impossible de la voir sous Dcom ni de l'enregistrer. Normal puisque c'est
une DLL ???

Bref, j'ai beau me relire, je suis encore loin du but ...
PS: J'ai aussi lu qu'avec VS 2005, le NET Remoting était déjà mort ? Ca se
complique :-) si c'est vrai. Qu'utiliser alors ?

D'avance merci
Pierre

"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message
de news: u3Zoz5JqEHA.592@TK2MSFTNGP11.phx.gbl...

**Pierre** wrote:
> A l'avenir, je veux aussi pouvoir faire des application dont certains
> composants résident sur le serveur pour l'accès aux données (access
> ou SQL server). Dans ce cadre, j'ai déjà eu la réponse suivante mais
> je n'ai pas encore résolu le problème :
>
> <<Avant de te lancer dans le remoting, tu peux également utiliser, les
> Composants dit EnterpriseServer.
> En gros ce sont des composants .NET qui pourront s'installer sur le
> serveur d'application Windows (COM+ disponible en standard sur nos
> servers) ainsi tu pourras profiter de tous les avantages. (Pooling
> d'objet, transaction Distribuées, etc....
> En utilisant ce serveur d'application, tu t'évites de développer toi
> même le serveur qui hostera ton composant.>>

Votre interlocuteur voulait sans doute parler du namespace
System.EnterpriseServices et de la classe ServicedComponent. Tout
composant .Net dérivé de cette classe est installable sous COM+ car il
sera vu comme un composant COM (voir la doc sur ce sujet). Une fois
installé sous COM+, ce composant sera utilisable par tout client
éloigné, .Net ou COM. Mais si le client est .Net, il vaut mieux utiliser
ce composant via .Net Remoting comme je l'ai déjà expliqué.

Si vous prévoyez que les composants en question seront utilisés à la
fois par des clients .Net et COM, la stratégie suivante est
envisageable:

1. Développez un composant .Net qui sera directement accessible via .Net
Remoting (pour les clients .Net).

2. Développez une classe dérivée de ServicedComponent qui déléguera ces
traitements au composant .Net cité en (1). Ce sera juste un front-end
qui ne fera qu'appeler les méthodes du composant principal. Installez ce
composant sous COM+.

3. De cette manière les clients auront le choix entre 2 canaux
d'activation qui se référeront en final au même code.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Bonjour,

Pierre wrote:

B: Faire du Net. Remoting avec une DLL .NET et l'encapsuler dans un
EXE qui me sert de Host sur le serveur. Le mettre dans un service
Windows ou lancer l'exe hosting avant d'appeler mon objet. Juste ?

Oui. La plupart du temps, l'exe servira d'interface à un assemblage
quelconque mais la DLL n'est pas obligatoire.

C: Faire du DCOM même avec une DLL .NET. Même si c'est idiot,
j'aimerai, pour bien pour comprendre, tester cette méthode et je ne
trouve pas comment faire. Auriez-vous un exemple. Dans les docs, j'ai
vu que l'ancien projet ActiveX.exe de VB6 se faisait avec un
composant .NET sous VB.NET mais je pense que celà suppose du NET
Remoting.

Non. Vous confondez. Là où on développait des ActiveX Controls, on
développe maintenant des Composants .Net. Cela n'a rien à voir avec .Net
Remoting. Si vous voulez activer le composant à distance, il faut le
prévoir d'entrée de jeu. Comme je l'ai déjà expliqué, la notion de
transparence qui permettait le passage de COM à DCOM par un simple jeu
de réglages n'existe pas en .Net. SI on crée un composant qui doit être
activé à distance, il faut le prévoir à l'avance, ça ne s'écrit pas de
la même manière.

Je reviens donc sur ma question : comment faire d'un projet
.NET un activeX.exe visible sous Dcom ? J'ai essayé avec une classe
dérivée de <System.EnterpriseServices> mais impossible de la voir
sous Dcom ni de l'enregistrer. Normal puisque c'est une DLL ???

Vous devez louper quelque chose. Il suffit de lancer Google avec les
mots-clé "ServicedComponent sample" pour trouver une foule d'articles et
d'exemples. Je ne peux pas vraiment pas faire mieux que ça. Voyez par
exemple:

http://www.oreilly.com/catalog/comdotnetsvs/chapter/ch10.html
http://www.ondotnet.com/pub/a/dotnet/excerpt/com_dotnet_ch10/index.html?page=1
http://www.dotnetjohn.com/articles.aspx?articleid2

Ces articles décrivent exactement la marche à suivre.

Notez que j'ai bien précisé qu'un composant .Net dérivant de
ServicedComponent s'installe sous **COM+**. Pour les autres cas, on
utilise le CCW (COM Callable Wrapper):

http://www.c-sharpcorner.com/articles/accessingdotnetfromcom.asp
http://www.c-sharpcorner.com/Code/2004/Aug/Interoperabilityin.NET.asp
http://www.15seconds.com/issue/010214.htm
http://searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci875413_tax292991,00.html
http://www.dnzone.com/ShowDetail.asp?NewsId6

Là, je crois que vous avez tous les éléments.

Bonne journée.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Merci, ca devrait suffir... pour l'instant :-))

"Patrick Philippot" <patrick.philippot@mainsoft.xx> a écrit dans le message
de news: #zJ#wHeqEHA.536@TK2MSFTNGP09.phx.gbl...

Bonjour,

Pierre wrote:
> B: Faire du Net. Remoting avec une DLL .NET et l'encapsuler dans un
> EXE qui me sert de Host sur le serveur. Le mettre dans un service
> Windows ou lancer l'exe hosting avant d'appeler mon objet. Juste ?

Oui. La plupart du temps, l'exe servira d'interface à un assemblage
quelconque mais la DLL n'est pas obligatoire.

> C: Faire du DCOM même avec une DLL .NET. Même si c'est idiot,
> j'aimerai, pour bien pour comprendre, tester cette méthode et je ne
> trouve pas comment faire. Auriez-vous un exemple. Dans les docs, j'ai
> vu que l'ancien projet ActiveX.exe de VB6 se faisait avec un
> composant .NET sous VB.NET mais je pense que celà suppose du NET
> Remoting.

Non. Vous confondez. Là où on développait des ActiveX Controls, on
développe maintenant des Composants .Net. Cela n'a rien à voir avec .Net
Remoting. Si vous voulez activer le composant à distance, il faut le
prévoir d'entrée de jeu. Comme je l'ai déjà expliqué, la notion de
transparence qui permettait le passage de COM à DCOM par un simple jeu
de réglages n'existe pas en .Net. SI on crée un composant qui doit être
activé à distance, il faut le prévoir à l'avance, ça ne s'écrit pas de
la même manière.

> Je reviens donc sur ma question : comment faire d'un projet
> .NET un activeX.exe visible sous Dcom ? J'ai essayé avec une classe
> dérivée de <System.EnterpriseServices> mais impossible de la voir
> sous Dcom ni de l'enregistrer. Normal puisque c'est une DLL ???

Vous devez louper quelque chose. Il suffit de lancer Google avec les
mots-clé "ServicedComponent sample" pour trouver une foule d'articles et
d'exemples. Je ne peux pas vraiment pas faire mieux que ça. Voyez par
exemple:

http://www.oreilly.com/catalog/comdotnetsvs/chapter/ch10.html

http://www.ondotnet.com/pub/a/dotnet/excerpt/com_dotnet_ch10/index.html?page=1

http://www.dotnetjohn.com/articles.aspx?articleid2

Ces articles décrivent exactement la marche à suivre.

Notez que j'ai bien précisé qu'un composant .Net dérivant de
ServicedComponent s'installe sous **COM+**. Pour les autres cas, on
utilise le CCW (COM Callable Wrapper):

http://www.c-sharpcorner.com/articles/accessingdotnetfromcom.asp
http://www.c-sharpcorner.com/Code/2004/Aug/Interoperabilityin.NET.asp
http://www.15seconds.com/issue/010214.htm

http://searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci875413_tax292991,00.html

http://www.dnzone.com/ShowDetail.asp?NewsId6

Là, je crois que vous avez tous les éléments.

Bonne journée.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr