Help in asp.net

[Support]

Currently our application is driven by ASP scripts and custom COM DLLs
written using VB 6.0.

The problem is our client wants to install the application on a shared
server which already has some other applications running. Currently none of
their applications are using any custom DLLs.

It seems they are not sure about our DLLs and are thinking that installing
any 3rd party DLLs might create some problems to the server. And hence they
are not ready to install our DLLs by any means i.e. neither by using COM+
Service (which we recommend) nor by manual registration using regsvr32.

Hence there is a need to make our application COM DLL less.

We can solve the problem in one of the 3 ways

a. Convert all our VB DLLs to classic ASP and performs changes to our
ASP scripts accordingly.

b. Port our application to .Net platform which our client supports.

c. We convince them on using something like COM+ and guarantee them
that it will not affect any of the current applications on the server.

 

[John Timney \(Microsoft MVP\)]

Sounds to me like the easiest and likey least cost approach would be to get
a second server to run this aplication on, given it is already completed.
For the sake of a few thousand dollars your problem could very easily be
solved and the risks they allude to would not be a concern.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP

 

[Jeff Johnson [MVP: VB]]

Please do not crosspost .NET questions between .NET and non-.NET newsgroups.
The *.vb.* groups are for VB6 and earlier.

 

[John Spiegel]

Hey Jeff,

I get that crossposting should be used with care, but given that the
original post is dealing in part with VB6-based DLLs and a potential
solution indicated is to remain with those DLLs, wouldn't this have been a
candidate for the VB6 newsgroup as well? Such a newsgroup could well be a
good target for those who may or may not be doing some .NET work but have a
lot of experience with when to stick with the older technologies.

I'm just looking to better understand NG etiquette.

Thanks,

John

 

[Jeff Johnson [MVP: VB]]

I get that crossposting should be used with care, but given that the
original post is dealing in part with VB6-based DLLs and a potential
solution indicated is to remain with those DLLs, wouldn't this have been a
candidate for the VB6 newsgroup as well?

True. If you knew how many .NET questions we get these days you'd understand
why we have a tendency to knee-jerk. The subject should have been phrased
better....

 

[Alan Silver]

We can solve the problem in one of the 3 ways

a. Convert all our VB DLLs to classic ASP and performs changes to
our
ASP scripts accordingly.

Which is a lot of work.

b. Port our application to .Net platform which our client
supports.

Which is even more work. The previous option would allow you to cut and
paste and get 99% of it working immediately. This is basically a
complete rewrite.

c. We convince them on using something like COM+ and guarantee
them
that it will not affect any of the current applications on the server.

If you are sure that this is true then this is your best option.

I can understand, but find sad, the blind objection to COM DLLs. If your
client trusts you enough to provide an application, don't they trust you
enough to put it in DLLs ? Would they have the same fears if you were
supplying a desktop application as EXE files ? Why is there any greater
cause for fear when the application happens to be housed in DLLs ?

I think you need to work on educating them ;-)