ActiveX Server?

[Tom Leylan]

Hope this is an easy question. I have a multi-tier app written in VB where
the server tier is an ActiveX .EXE project. I'm going to convert it to
VB.Net and I'm not sure what to choose as the project type.

It has no window. Is this a "Windows Service" or just a Windows app with no
window?

Thanks,
Tom

 

[Tom Spink]

Hi there, you cannot build Active-X components with VB.NET.

Could you provide a bit more information on what your app does?

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations

 

[Herfried K. Wagner [MVP]]

Hope this is an easy question. I have a multi-tier app written in VB where
the server tier is an ActiveX .EXE project. I'm going to convert it to
VB.Net and I'm not sure what to choose as the project type.

You cannot write an ActiveX server with .NET.

 

[Tom Leylan]

Could you provide a bit more information on what your app does?

I was searching around but nobody put it quite that clearly

Basically the current setup includes an .EXE that is installed on the
database server. A client application (also .EXE) can reference a .DLL that
resides on the client also instantiating objects. Those objects can send
data to and receive data from the .EXE on the server via byte streams.

The .DLL would have a CreateObject() call with the name of the server and
object I need created and once I have the reference I can tell it to send me
the data I need.

Neither the client .EXE or the client-side .DLL knows about ADO or where and
how the data is stored. The data streams are reconstituted into objects on
the client side and that's all the client knows about.

Gosh I hope this isn't something they plan on adding in the future

In case anybody asks, this isn't a web server, it isn't accessed by a
browser and I don't want HTML back. I might be able to work with XML but
that isn't as handy as the way it currently works.

Thanks,
Tom

 

[Taiwo]

Tom,

The primary reason to use an ActiveX EXE server is for process isolation. So
even though you used an ActiveX EXE server in your current project, you
could have compiled the component as an ActiveX DLL and host it in COM+
services.

Therefore, simply port your ActiveX EXE code to .NET DLL Assembly but host
it in COM+ services (formerly MTS). Look at the ServicedComponent class in
the .NET Frameworks. Check out these links for examples:

http://www.gotdotnet.com/team/xmlentsvcs/espaper.aspx
http://www.gotdotnet.com/team/xmlentsvcs/esfaq.aspx

In fact, COM+ services in Windows 2003 can host your .NET DLL as a Windows
Service if you specify.

Cheers,

Taiwo

 

[Tom Leylan]

Therefore, simply port your ActiveX EXE code to .NET DLL Assembly but host
it in COM+ services (formerly MTS). Look at the ServicedComponent class in
the .NET Frameworks. Check out these links for examples:

Thanks for the links I'll read everything over. The current system didn't
require MTS but if that's the way it has to go I guess I don't have a lot of
choices. I'll cross my fingers it is as simple a "simple port" as you seem
to indicate

Tom

 

[Brian Adams]

If you don't like the ServicedComponent option, take a
look at the different Remoting models. Remoting is, in
simple terms, .NET's alternative to DCOM. Personally, I
believe this is the best way to go if you are porting
everything to .NET. If you keep Component Services out of
the mix, you will be able to reduce or eliminate the
Interop penalty. You can marshal data using the
BinaryFormatter, which will keep XML out of the mix, as
you stated you would like, and allow you to continue using
Byte streams.

Brian