Help me I am going insane (ActiveX deployment and DLL HELL).

[owen]

First, a little background: I have developed an ActiveX control that I want
various IE clients to access using their web browsers. These clients will
have various operating systems (Win98, XP, 2000, NT, etc) but always the
browser would be IE5.0 upward. My ActiveX control was developed using VB6
and calls to MSSOAP30.DLL (Version 3.00.1325.0). Put simply, I use that
particular DLL to do stuff with XML in my VB6 code. And it works fine, at
least on my development PC.

A client PC has Office 2003 installed, which just happens to include it's
own version of MSSOAP30.DLL. (Version 3.00.1906.0). Oh dear. This is a
different version to that on my development PC. Doesn't bode well...

Initially, this caused the deployment to fail miserably. (It failed to
register and/or install MSSOAP30.DLL on the client, because it already
existed in a "MS Office" folder. It resulted in the "red X" being displayed
in place of the control). So, as an experiment, I excluded MSSOAP30.DLL
from the distribution package, and sure enough, this time it deployed and
displayed on the client. BUT, it didn't work. There were runtime errors,
because the code was developed with a different version of MSSOAP30.DLL to
that on the client PC.

HOW am I supposed to deploy my ActiveX control in a way that works
regardless of the user's existing DLL's? There is no way I can force them
to use the same version of MSSOAP30.DLL that I developed with. But
likewise, I cannot change my VB project to use any particular version of the
DLL, because another end-user may not have that version on their PC. And I
cannot simply exclude MSSOAP30.DLL from the build, because that stops it
working on anybody's PC who doesnt have that DLL. I just want my code to
work on ALL end-user's PCs - but I cannot either overwrite their DLLs nor
use their existing DLLs.

So WHAT am I supposed to do?????

Please help me.

Owen

PS. replies cc'd by email VERY welcome.
(e-mail address removed)

 

[Jay]

This may not be feasible, it may not even be a working solution but...
Would porting the app to dot net and using the xml namespaces therein work?
Admittedly your clients would need the dot net framework installed but you
could tell them that you've switched to dot net in order to take advantage
of XYZ functionality )

Jay

 

[owen]

This may not be feasible, it may not even be a working solution but...
Would porting the app to dot net and using the xml namespaces therein work?
Admittedly your clients would need the dot net framework installed but you
could tell them that you've switched to dot net in order to take advantage
of XYZ functionality )

Well, Jay, processing XML in .Net is certainly a lot more straightforward -
for one thing it doesn't require any special stuff like "SOAP Toolkit" to be
installed. Unfortunately though, my project has to be an ActiveX control
and therefore has to be done in old fashioned VB6. (You cant do ActiveX in
..Net as far as I know).

Owen

 

[Jon]

Just a thought .. but would including the latest installer for MS SOAP
Toolkit 3.0 (not sure if it contains the dll version you want)

http://www.microsoft.com/downloads/...DD-CEEC-4088-9753-86F052EC8450&displaylang=en

with your setup package be an option or would that cause problems with
packages like Office 2003?


Jon

 

[mayayana]

I'm not sure if this will help, but if it were me
I'd check two things:

1) Are there depencies for MSSOAP30.DLL that may
not be installed?

2) If you're sure that it works with one version of MSSOAP.DLL
and not with another, then probably you're using functionality
that's not included in an earlier version. You could check to
see whether you might be able to avoid using those specific
functions that aren't in the the earlier version.

3) If the DLL is not a COM DLL, research whether your version
can be safely installed to the system folder without causing
conflicts in Office.

 

[Jay]

Well, Jay, processing XML in .Net is certainly a lot more straightforward -
for one thing it doesn't require any special stuff like "SOAP Toolkit" to be
installed. Unfortunately though, my project has to be an ActiveX control
and therefore has to be done in old fashioned VB6. (You cant do ActiveX in
.Net as far as I know).

Oh ok.
I know you can drop ActiveX components into your project/solution.
Wasn't sure if you could "build" the project as ActiveX though.

Jay