Porting VB6 ActiveX EXE Component to dotNET

[David]

Hi everyone,

I have a ActiveX EXE component written in VB6. This ActiveX EXE exposes
various public methods that can be called by several other independent
Windows EXE applications (also written in VB6).

I would like to port the ActiveX EXE component it to dotNet. What type of
project that I should port it to? A Windows Service or what? Please suggest.

The thing is that I will not be porting the existing Windows EXE
applications to dotNet yet. So if I port the VB6 ActiveX EXE to a Windows
Service (or anything that is appropriate) will VB6 applications still be
able to communicate with the new dotNet Windows Service (just like they
could with ActiveX EXE)?

Thanks,
David

[Imran Koradia]

There's no general rule as such for porting from VB6 to VB.NET. I would
suggest reading this first:
http://msdn.microsoft.com/vbasic/usi...g/default.aspx
That should give you some details on migrating from VB6 to VB.NET.

Also, check this out:
http://www.microsoft.com/israel/vbas...h/default.mspx
It contains slides/presentations about why to migrate, when to migrate, etc

hope that helps a bit..
Imran.
"David" <no******@mailingspam.com> wrote in message
news:uA**************@TK2MSFTNGP12.phx.gbl...

Hi everyone,

I have a ActiveX EXE component written in VB6. This ActiveX EXE exposes
various public methods that can be called by several other independent
Windows EXE applications (also written in VB6).

I would like to port the ActiveX EXE component it to dotNet. What type of
project that I should port it to? A Windows Service or what? Please
suggest.

The thing is that I will not be porting the existing Windows EXE
applications to dotNet yet. So if I port the VB6 ActiveX EXE to a Windows
Service (or anything that is appropriate) will VB6 applications still be
able to communicate with the new dotNet Windows Service (just like they
could with ActiveX EXE)?

Thanks,
David

[Tom Shelton]

On Thu, 9 Sep 2004 14:59:14 +1200, David wrote:

Hi everyone,

I have a ActiveX EXE component written in VB6. This ActiveX EXE exposes
various public methods that can be called by several other independent
Windows EXE applications (also written in VB6).

I would like to port the ActiveX EXE component it to dotNet. What type of
project that I should port it to? A Windows Service or what? Please suggest.

The thing is that I will not be porting the existing Windows EXE
applications to dotNet yet. So if I port the VB6 ActiveX EXE to a Windows
Service (or anything that is appropriate) will VB6 applications still be
able to communicate with the new dotNet Windows Service (just like they
could with ActiveX EXE)?

Thanks,
David

Hmmm, well I would say to look at remoting in the documentation - since
that would roughly corrispond to an activex exe. But, since you aren't
converting the clients to .NET - I would say you're better off not
converting the activex exe. In fact, I would port the clients first - and
let them continue to use the activex exe via interop. After they were
ported, I would port the activex exe and use remoting. That way, you could
convert the applications one at a time - and they should still work :)

--
Tom Shelton [MVP]

[David]

Hi Tom,

Thanks for the reply.

The problem is that I've created the clients in VB6 and I have not created
the ActiveX EXE application in VB6 yet! It's still in the design phase and I
was wondering would it be better off to create that ActiveX EXE in dotNet
equivalent (because I have plans to port VB6 clients to dotNet in the
future).

Any suggestions?
David

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:ec*****************************@40tude.net...

On Thu, 9 Sep 2004 14:59:14 +1200, David wrote:

Hi everyone,

I have a ActiveX EXE component written in VB6. This ActiveX EXE exposes
various public methods that can be called by several other independent
Windows EXE applications (also written in VB6).

I would like to port the ActiveX EXE component it to dotNet. What type of
project that I should port it to? A Windows Service or what? Please
suggest.

The thing is that I will not be porting the existing Windows EXE
applications to dotNet yet. So if I port the VB6 ActiveX EXE to a Windows
Service (or anything that is appropriate) will VB6 applications still be
able to communicate with the new dotNet Windows Service (just like they
could with ActiveX EXE)?

Thanks,
David

Hmmm, well I would say to look at remoting in the documentation - since
that would roughly corrispond to an activex exe. But, since you aren't
converting the clients to .NET - I would say you're better off not
converting the activex exe. In fact, I would port the clients first - and
let them continue to use the activex exe via interop. After they were
ported, I would port the activex exe and use remoting. That way, you
could
convert the applications one at a time - and they should still work :)

--
Tom Shelton [MVP]

[David]

Hi Tom,

Thanks for the reply.

The problem is that I've created the clients in VB6 and I have not created
the ActiveX EXE application in VB6 yet! It's still in the design phase and I
was wondering would it be better off to create that ActiveX EXE in dotNet
equivalent (because I have plans to port VB6 clients to dotNet in the
future).

Any suggestions?
David

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:ec*****************************@40tude.net...

On Thu, 9 Sep 2004 14:59:14 +1200, David wrote:

Hi everyone,

I have a ActiveX EXE component written in VB6. This ActiveX EXE exposes
various public methods that can be called by several other independent
Windows EXE applications (also written in VB6).

I would like to port the ActiveX EXE component it to dotNet. What type of
project that I should port it to? A Windows Service or what? Please
suggest.

The thing is that I will not be porting the existing Windows EXE
applications to dotNet yet. So if I port the VB6 ActiveX EXE to a Windows
Service (or anything that is appropriate) will VB6 applications still be
able to communicate with the new dotNet Windows Service (just like they
could with ActiveX EXE)?

Thanks,
David

Hmmm, well I would say to look at remoting in the documentation - since
that would roughly corrispond to an activex exe. But, since you aren't
converting the clients to .NET - I would say you're better off not
converting the activex exe. In fact, I would port the clients first - and
let them continue to use the activex exe via interop. After they were
ported, I would port the activex exe and use remoting. That way, you
could
convert the applications one at a time - and they should still work :)

--
Tom Shelton [MVP]

[Paul Clement]

On Thu, 9 Sep 2004 16:10:32 +1200, "David" <no******@mailingspam.com> wrote:

¤ Hi Tom,
¤
¤ Thanks for the reply.
¤
¤ The problem is that I've created the clients in VB6 and I have not created
¤ the ActiveX EXE application in VB6 yet! It's still in the design phase and I
¤ was wondering would it be better off to create that ActiveX EXE in dotNet
¤ equivalent (because I have plans to port VB6 clients to dotNet in the
¤ future).
¤

There isn't a direct equivalent, however you could develop a .NET web service (or use binary
remoting) and use SOAP to communicate with the VB 6.0 application.

http://support.microsoft.com/default...b;en-us;325248
Paul ~~~ pc******@ameritech.net
Microsoft MVP (Visual Basic)