Equivalent of an Activex EXE in VB.Net

[Nikkita]

Software such as Excel or Word exposes a COM object model which allows
them to be automated by any language that can call COM objects.

As I understand it, I can do the same in VB6 by writing an Activex EXE.
Such a program can have a GUI which will be accessed by users in the
normal way as well as exposing a COM object model.

How can I do the .Net equivalent in VB.Net? According to VB.Net help, the
VB.Net equivalent of an Activex EXE is a Class Library. But a Class
Library project doesn't appear to allow me to choose a starting point -
it's only intended to export objects to be called from elsewhere. This is
all very well but how do I write a program in VB.Net with a GUI which can
also export its object model to allow it to be automated/consumed by other
programs?

 

[Tom Shelton]

Software such as Excel or Word exposes a COM object model which allows
them to be automated by any language that can call COM objects.

As I understand it, I can do the same in VB6 by writing an Activex EXE.
Such a program can have a GUI which will be accessed by users in the
normal way as well as exposing a COM object model.

How can I do the .Net equivalent in VB.Net? According to VB.Net help, the
VB.Net equivalent of an Activex EXE is a Class Library. But a Class
Library project doesn't appear to allow me to choose a starting point -
it's only intended to export objects to be called from elsewhere. This is
all very well but how do I write a program in VB.Net with a GUI which can
also export its object model to allow it to be automated/consumed by other
programs?

The closest equivalent would be .NET remoting... Your application can
host objects that other processes can get hold of and send commands.

 

[Oenone]

How can I do the .Net equivalent in VB.Net?

If it helps, you can reference .exes in VS2005...

 

[Chris Dunaway]

You would have to create a Class Library that exposes your object
model. It can also contain GUI elements like forms and dialog boxes.
You would then have to create a Windows Forms Application to allow the
app to run stand alone.

As was pointed out by Oenone, VS2005 will allow the referencing of
..exe's

 

[Guest]

Just FYI, the VS.NET 2003 IDE does not allow you to reference *.exe files.
However, if you compile your project through the command line, it will allow
you to reference *.exe files. Try it out, it works

 

[Nikkita]

Software such as Excel or Word exposes a COM object model which
allows them to be automated by any language that can call COM objects.

As I understand it, I can do the same in VB6 by writing an Activex
EXE. Such a program can have a GUI which will be accessed by users in
the normal way as well as exposing a COM object model.

How can I do the .Net equivalent in VB.Net? According to VB.Net help,
the VB.Net equivalent of an Activex EXE is a Class Library. But a
Class Library project doesn't appear to allow me to choose a starting
point - it's only intended to export objects to be called from
elsewhere. This is all very well but how do I write a program in
VB.Net with a GUI which can also export its object model to allow it
to be automated/consumed by other programs?

The closest equivalent would be .NET remoting... Your application can
host objects that other processes can get hold of and send commands.[/QUOTE]

Thanks, I'll look into that.

 

[Nikkita]

If it helps, you can reference .exes in VS2005...

Thanks, this could be useful.

 

[Nikkita]

You would have to create a Class Library that exposes your object
model. It can also contain GUI elements like forms and dialog boxes.
You would then have to create a Windows Forms Application to allow the
app to run stand alone.

As was pointed out by Oenone, VS2005 will allow the referencing of
.exe's

I see, thanks for your help. Things are becoming clearer now.

 

[Nikkita]

Just FYI, the VS.NET 2003 IDE does not allow you to reference *.exe
files. However, if you compile your project through the command line,
it will allow you to reference *.exe files. Try it out, it works

That's very interesting, thanks. I'll take a look at that.