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/using/migrating/default.aspx
That should give you some details on migrating from VB6 to VB.NET.

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

hope that helps a bit..
Imran.

 

[Tom Shelton]

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

 

[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

 

[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

 

[Paul Clement]

¤ 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.aspx?scid=kb;en-us;325248


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)