By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,244 Members | 1,972 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,244 IT Pros & Developers. It's quick & easy.

Porting VB6 ActiveX EXE Component to dotNET

P: n/a
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
Jul 21 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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

Jul 21 '05 #2

P: n/a
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]
Jul 21 '05 #3

P: n/a
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]

Jul 21 '05 #4

P: n/a
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]

Jul 21 '05 #5

P: n/a
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)
Jul 21 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.