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

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


"Tom Leylan" <(E-Mail Removed)> wrote in message
news:waHhb.31523$(E-Mail Removed)...
> 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 Leylan" <(E-Mail Removed)> scripsit:
> 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.

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

"Tom Spink" <(E-Mail Removed)> wrote...
> 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

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" <(E-Mail Removed)> wrote in message
news:PTHhb.62408$(E-Mail Removed)...
> "Tom Spink" <(E-Mail Removed)> wrote...
> > 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" <(E-Mail Removed)> wrote...

> 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

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


>-----Original Message-----
>"Taiwo" <(E-Mail Removed)> wrote...
>
>> 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
>
>
>.
>