Bonjour
Je suis actuellement en train d'étudier une migration d'une architecture
VB6/ASP avec COM/DCOM vers
une architecture Dotnet.
Je dois présenter les principales solutions pour arriver à terme vers une
version "pure" Dotnet.
Je vais axer mon étude :
- Sur une migration progressive tout en utilisant la couche interop de .net
et donc de continuer à utiliser mes ActivesX VB6
et de recoder mes parties présentations et métiers .
- Ou sur une migration "totale" c a d pas de période de coéxistance des 2
plateformes.
D'apres mes recherches la version DCOM de .NET est le remoting ?
En ce qui concerne la migration totale, pas de problème j'ai déja une
architecture bien définie.
Or en ce qui concerne une migration progressive , je ne absolument vois pas
comment faire ...
Y a t il quelqu'un pour m'aiguiller dans tout cela ?
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
Eric Vernié [MS]
Bonjour Chnew,
Si j'ai bien compris, tu veux remplacer DCOM par Remoting Cela veut dire que tu as développé un serveur DCOM en VB6 ? Exemple : ASP->(CreateObject())->DCOM->EXE(VB6)->ACTIVEX.DLL(VB6)
Tu me corriges si je me trompe.
Tu pourrais t'éviter une phase de développement (Remoting) uniquement en tirant profit du Serveur d'application Windows, c'est à dire en inscrivant OBJET.DLL dans une application COM+
Tu migres l'interface utilisateur de ASP vers ASP.NET, et tu inscrit tes activeX VB 6 dans le catalogue COM+
Ensuite tu re-ecrit tes composants ActiveX VB 6 en composant .NET qui devront alors prendre en charge l'espace de nom System.EnterpriseServices, et dériver de la classe ServiceComponent. En utilisant ce type d'architecture, tes composants .NET pourrons profiter de la puissance du Serveur d'application Windows -Transaction distribué, evenement, pooling d'objet, sécurité etc... Le protocole de communication sera toujours du DCOM (même avec le composant .NET), par contre tu t'évites la phase de développement du host de tes composants.
A+
Eric Vernié Microsoft France
PS: Le serveur d'application COM+ est souvent négligé, et pourtant il est eprouvé depuis longtemps dans des architectures robustes.
"Chnew" a écrit dans le message de news:
Bonjour Je suis actuellement en train d'étudier une migration d'une architecture VB6/ASP avec COM/DCOM vers une architecture Dotnet.
Je dois présenter les principales solutions pour arriver à terme vers une version "pure" Dotnet.
Je vais axer mon étude :
- Sur une migration progressive tout en utilisant la couche interop de .net et donc de continuer à utiliser mes ActivesX VB6 et de recoder mes parties présentations et métiers .
- Ou sur une migration "totale" c a d pas de période de coéxistance des 2 plateformes.
D'apres mes recherches la version DCOM de .NET est le remoting ? En ce qui concerne la migration totale, pas de problème j'ai déja une architecture bien définie. Or en ce qui concerne une migration progressive , je ne absolument vois pas comment faire ...
Y a t il quelqu'un pour m'aiguiller dans tout cela ?
Bonjour Chnew,
Si j'ai bien compris, tu veux remplacer DCOM par Remoting
Cela veut dire que tu as développé un serveur DCOM en VB6 ?
Exemple :
ASP->(CreateObject())->DCOM->EXE(VB6)->ACTIVEX.DLL(VB6)
Tu me corriges si je me trompe.
Tu pourrais t'éviter une phase de développement (Remoting) uniquement en
tirant profit du Serveur d'application Windows, c'est à dire en inscrivant
OBJET.DLL dans une application COM+
Tu migres l'interface utilisateur de ASP vers ASP.NET, et tu inscrit tes
activeX VB 6 dans le catalogue COM+
Ensuite tu re-ecrit tes composants ActiveX VB 6 en composant .NET qui
devront alors prendre en charge l'espace de nom System.EnterpriseServices,
et dériver de la classe ServiceComponent. En utilisant ce type
d'architecture, tes composants .NET pourrons profiter de la puissance du
Serveur d'application Windows
-Transaction distribué, evenement, pooling d'objet, sécurité etc...
Le protocole de communication sera toujours du DCOM (même avec le composant
.NET), par contre tu t'évites la phase de développement du host de tes
composants.
A+
Eric Vernié
Microsoft France
PS:
Le serveur d'application COM+ est souvent négligé, et pourtant il est
eprouvé depuis longtemps dans des architectures robustes.
"Chnew" <Chnew@discussions.microsoft.com> a écrit dans le message de news:
EFCC4015-F4C4-4BA1-8E9E-53E3967298A4@microsoft.com...
Bonjour
Je suis actuellement en train d'étudier une migration d'une architecture
VB6/ASP avec COM/DCOM vers
une architecture Dotnet.
Je dois présenter les principales solutions pour arriver à terme vers une
version "pure" Dotnet.
Je vais axer mon étude :
- Sur une migration progressive tout en utilisant la couche interop de
.net
et donc de continuer à utiliser mes ActivesX VB6
et de recoder mes parties présentations et métiers .
- Ou sur une migration "totale" c a d pas de période de coéxistance des 2
plateformes.
D'apres mes recherches la version DCOM de .NET est le remoting ?
En ce qui concerne la migration totale, pas de problème j'ai déja une
architecture bien définie.
Or en ce qui concerne une migration progressive , je ne absolument vois
pas
comment faire ...
Y a t il quelqu'un pour m'aiguiller dans tout cela ?
Si j'ai bien compris, tu veux remplacer DCOM par Remoting Cela veut dire que tu as développé un serveur DCOM en VB6 ? Exemple : ASP->(CreateObject())->DCOM->EXE(VB6)->ACTIVEX.DLL(VB6)
Tu me corriges si je me trompe.
Tu pourrais t'éviter une phase de développement (Remoting) uniquement en tirant profit du Serveur d'application Windows, c'est à dire en inscrivant OBJET.DLL dans une application COM+
Tu migres l'interface utilisateur de ASP vers ASP.NET, et tu inscrit tes activeX VB 6 dans le catalogue COM+
Ensuite tu re-ecrit tes composants ActiveX VB 6 en composant .NET qui devront alors prendre en charge l'espace de nom System.EnterpriseServices, et dériver de la classe ServiceComponent. En utilisant ce type d'architecture, tes composants .NET pourrons profiter de la puissance du Serveur d'application Windows -Transaction distribué, evenement, pooling d'objet, sécurité etc... Le protocole de communication sera toujours du DCOM (même avec le composant .NET), par contre tu t'évites la phase de développement du host de tes composants.
A+
Eric Vernié Microsoft France
PS: Le serveur d'application COM+ est souvent négligé, et pourtant il est eprouvé depuis longtemps dans des architectures robustes.
"Chnew" a écrit dans le message de news:
Bonjour Je suis actuellement en train d'étudier une migration d'une architecture VB6/ASP avec COM/DCOM vers une architecture Dotnet.
Je dois présenter les principales solutions pour arriver à terme vers une version "pure" Dotnet.
Je vais axer mon étude :
- Sur une migration progressive tout en utilisant la couche interop de .net et donc de continuer à utiliser mes ActivesX VB6 et de recoder mes parties présentations et métiers .
- Ou sur une migration "totale" c a d pas de période de coéxistance des 2 plateformes.
D'apres mes recherches la version DCOM de .NET est le remoting ? En ce qui concerne la migration totale, pas de problème j'ai déja une architecture bien définie. Or en ce qui concerne une migration progressive , je ne absolument vois pas comment faire ...
Y a t il quelqu'un pour m'aiguiller dans tout cela ?
Chnew
oui c'est bien cela mais je ne connaissait pas d'autres alternatives ... je vais etudier l'usage du COM + que tu m'as decrites .
Merci beaucoup
"Eric Vernié [MS]" a écrit :
Bonjour Chnew,
Si j'ai bien compris, tu veux remplacer DCOM par Remoting Cela veut dire que tu as développé un serveur DCOM en VB6 ? Exemple : ASP->(CreateObject())->DCOM->EXE(VB6)->ACTIVEX.DLL(VB6)
Tu me corriges si je me trompe.
Tu pourrais t'éviter une phase de développement (Remoting) uniquement en tirant profit du Serveur d'application Windows, c'est à dire en inscrivant OBJET.DLL dans une application COM+
Tu migres l'interface utilisateur de ASP vers ASP.NET, et tu inscrit tes activeX VB 6 dans le catalogue COM+
Ensuite tu re-ecrit tes composants ActiveX VB 6 en composant .NET qui devront alors prendre en charge l'espace de nom System.EnterpriseServices, et dériver de la classe ServiceComponent. En utilisant ce type d'architecture, tes composants .NET pourrons profiter de la puissance du Serveur d'application Windows -Transaction distribué, evenement, pooling d'objet, sécurité etc... Le protocole de communication sera toujours du DCOM (même avec le composant ..NET), par contre tu t'évites la phase de développement du host de tes composants.
A+
Eric Vernié Microsoft France
PS: Le serveur d'application COM+ est souvent négligé, et pourtant il est eprouvé depuis longtemps dans des architectures robustes.
"Chnew" a écrit dans le message de news:
> Bonjour > Je suis actuellement en train d'étudier une migration d'une architecture > VB6/ASP avec COM/DCOM vers > une architecture Dotnet. > > Je dois présenter les principales solutions pour arriver à terme vers une > version "pure" Dotnet. > > Je vais axer mon étude : > > - Sur une migration progressive tout en utilisant la couche interop de > .net > et donc de continuer à utiliser mes ActivesX VB6 > et de recoder mes parties présentations et métiers . > > - Ou sur une migration "totale" c a d pas de période de coéxistance des 2 > plateformes. > > D'apres mes recherches la version DCOM de .NET est le remoting ? > En ce qui concerne la migration totale, pas de problème j'ai déja une > architecture bien définie. > Or en ce qui concerne une migration progressive , je ne absolument vois > pas > comment faire ... > > Y a t il quelqu'un pour m'aiguiller dans tout cela ? > >
oui c'est bien cela
mais je ne connaissait pas d'autres alternatives ...
je vais etudier l'usage du COM + que tu m'as decrites .
Merci beaucoup
"Eric Vernié [MS]" a écrit :
Bonjour Chnew,
Si j'ai bien compris, tu veux remplacer DCOM par Remoting
Cela veut dire que tu as développé un serveur DCOM en VB6 ?
Exemple :
ASP->(CreateObject())->DCOM->EXE(VB6)->ACTIVEX.DLL(VB6)
Tu me corriges si je me trompe.
Tu pourrais t'éviter une phase de développement (Remoting) uniquement en
tirant profit du Serveur d'application Windows, c'est à dire en inscrivant
OBJET.DLL dans une application COM+
Tu migres l'interface utilisateur de ASP vers ASP.NET, et tu inscrit tes
activeX VB 6 dans le catalogue COM+
Ensuite tu re-ecrit tes composants ActiveX VB 6 en composant .NET qui
devront alors prendre en charge l'espace de nom System.EnterpriseServices,
et dériver de la classe ServiceComponent. En utilisant ce type
d'architecture, tes composants .NET pourrons profiter de la puissance du
Serveur d'application Windows
-Transaction distribué, evenement, pooling d'objet, sécurité etc...
Le protocole de communication sera toujours du DCOM (même avec le composant
..NET), par contre tu t'évites la phase de développement du host de tes
composants.
A+
Eric Vernié
Microsoft France
PS:
Le serveur d'application COM+ est souvent négligé, et pourtant il est
eprouvé depuis longtemps dans des architectures robustes.
"Chnew" <Chnew@discussions.microsoft.com> a écrit dans le message de news:
EFCC4015-F4C4-4BA1-8E9E-53E3967298A4@microsoft.com...
> Bonjour
> Je suis actuellement en train d'étudier une migration d'une architecture
> VB6/ASP avec COM/DCOM vers
> une architecture Dotnet.
>
> Je dois présenter les principales solutions pour arriver à terme vers une
> version "pure" Dotnet.
>
> Je vais axer mon étude :
>
> - Sur une migration progressive tout en utilisant la couche interop de
> .net
> et donc de continuer à utiliser mes ActivesX VB6
> et de recoder mes parties présentations et métiers .
>
> - Ou sur une migration "totale" c a d pas de période de coéxistance des 2
> plateformes.
>
> D'apres mes recherches la version DCOM de .NET est le remoting ?
> En ce qui concerne la migration totale, pas de problème j'ai déja une
> architecture bien définie.
> Or en ce qui concerne une migration progressive , je ne absolument vois
> pas
> comment faire ...
>
> Y a t il quelqu'un pour m'aiguiller dans tout cela ?
>
>
oui c'est bien cela mais je ne connaissait pas d'autres alternatives ... je vais etudier l'usage du COM + que tu m'as decrites .
Merci beaucoup
"Eric Vernié [MS]" a écrit :
Bonjour Chnew,
Si j'ai bien compris, tu veux remplacer DCOM par Remoting Cela veut dire que tu as développé un serveur DCOM en VB6 ? Exemple : ASP->(CreateObject())->DCOM->EXE(VB6)->ACTIVEX.DLL(VB6)
Tu me corriges si je me trompe.
Tu pourrais t'éviter une phase de développement (Remoting) uniquement en tirant profit du Serveur d'application Windows, c'est à dire en inscrivant OBJET.DLL dans une application COM+
Tu migres l'interface utilisateur de ASP vers ASP.NET, et tu inscrit tes activeX VB 6 dans le catalogue COM+
Ensuite tu re-ecrit tes composants ActiveX VB 6 en composant .NET qui devront alors prendre en charge l'espace de nom System.EnterpriseServices, et dériver de la classe ServiceComponent. En utilisant ce type d'architecture, tes composants .NET pourrons profiter de la puissance du Serveur d'application Windows -Transaction distribué, evenement, pooling d'objet, sécurité etc... Le protocole de communication sera toujours du DCOM (même avec le composant ..NET), par contre tu t'évites la phase de développement du host de tes composants.
A+
Eric Vernié Microsoft France
PS: Le serveur d'application COM+ est souvent négligé, et pourtant il est eprouvé depuis longtemps dans des architectures robustes.
"Chnew" a écrit dans le message de news:
> Bonjour > Je suis actuellement en train d'étudier une migration d'une architecture > VB6/ASP avec COM/DCOM vers > une architecture Dotnet. > > Je dois présenter les principales solutions pour arriver à terme vers une > version "pure" Dotnet. > > Je vais axer mon étude : > > - Sur une migration progressive tout en utilisant la couche interop de > .net > et donc de continuer à utiliser mes ActivesX VB6 > et de recoder mes parties présentations et métiers . > > - Ou sur une migration "totale" c a d pas de période de coéxistance des 2 > plateformes. > > D'apres mes recherches la version DCOM de .NET est le remoting ? > En ce qui concerne la migration totale, pas de problème j'ai déja une > architecture bien définie. > Or en ce qui concerne une migration progressive , je ne absolument vois > pas > comment faire ... > > Y a t il quelqu'un pour m'aiguiller dans tout cela ? > >
