ActiveX deployment fails

[Steve]

I am having an issue deploying an ActiveX control. This
is a .NET project in C#. The ActiveX control is written
in VB6. I use the PDW (Package and Deployment Wizard) to
create a .CAB for the control.

The problem is that sometimes the ActiveX control installs
successfully and sometimes it doesn't. We have various
test machines running different operating systems. On one
machine, running Windows 2000, SP4, the control installs
successfully. On another running Windows XP Professional,
SP1, the control does not install. It also fails on other
machines (like the customer's machine) but I do not have a
list of operating systems or other stats on those machines.

The error message I get is this:

*** Code Download Log entry (09 Nov 2004 @ 11:04:57) ***
Code Download Error: (hr = 800c0300) Unknown Error!!
Operation failed. Detailed Information:
CodeBase:http://kwmqasite2/ocx/KwmActiveXControls.CAB
CLSID: {24959835-9D2A-40AA-B6B2-9BA0905D47F0}
Extension:
Type:

LOG: Item KwmActiveXControls.ocx being processed.
--- Detailed Error Log Follows ---
LOG: Download OnStopBinding called (hrStatus = 0 /
hrResponseHdr = 0).
LOG: Item KwmActiveXControls.ocx being processed.
LOG: Item KSPBCO.dll being processed.
LOG: Item scrrun.dll being processed.
LOG: Item msvcrt.dll being processed.
LOG: Item msxml3.dll being processed.
LOG: Item KSCTL.dll being processed.
LOG: Item winhttp.dll being processed.
ERR: INF Processing: Failed (800c0300) processing:
winhttp.dll. Cannot get primary/default language!LOG: URL
Download Complete: hrStatus:0, hrOSB:800c0300,
hrResponseHdr:0,
URL:(http://kwmqasite2/ocx/KwmActiveXControls.CAB)
LOG: Reporting Code Download Completion: (hr:800c0300
(FAILED), CLASSID: 24959835..., szCODE:
(http://kwmqasite2/ocx/KwmActiveXControls.CAB),
MainType:(null), MainExt:(null))

Researching this on Google does not reveal a heck of a
lot. This issue seems to be common and no one has
discovered the underlying cause or a solution.

Grasping at straws, I put together a table of the dlls in
the log and the versions.

DLL .cab file Windows 2000 Windows XP
(succeeded) (failed)
scrrun 5.6.0.6626 5.6.0.6626 5.6.0.6626
msvcrt 6.1.9844.0 6.1.9844.0 7.0.2600.1106
msxml3 8.30.9926.0 8.30.9926.0 8.30.9926.0
winhttp 5.1.2600.1327 5.1.2600.1327 5.1.2600.1108
The log says that the problem is winhttp.dll. This may or
may not be the issue. The only difference I can see is
that the version number is different on the client machine
where it failed. Then again, the msvcrt also has a
different version number, albeit a later one.

Could the problem be the version number? Or is it
something else. No one seems to have an answer to this
and I am hoping someone on this board has some brilliant
insight.

Thanks.

[Steve]

I figured out the problem and I am posting it here so
others who have this issue can benefit.

What is happening is when I install the ActiveX control,
the installer checks the version of some of the system
files (such as winhttp.dll, msxml3.dll) that I included in
the packaging (Packaging and Deployment Wizard) against
what is on the client. If the client has earlier
versions, the installer tries to install the newer
version. The problem is winhttp.dll (for example) is in
use. Consequently, the installer encounters an error when
it tries to replace it and fails. (I can't believe
Microsoft doesn't handle this exception in the code!!)

The solution is to decide whether these system files are
actually required for the ActiveX control when it is
packaged. If not, remove them from the CAB file and that
will solve the problem.

-----Original Message-----
I am having an issue deploying an ActiveX control. This
is a .NET project in C#. The ActiveX control is written
in VB6. I use the PDW (Package and Deployment Wizard) to
create a .CAB for the control.

The problem is that sometimes the ActiveX control installssuccessfully and sometimes it doesn't. We have various
test machines running different operating systems. On onemachine, running Windows 2000, SP4, the control installs
successfully. On another running Windows XP Professional,SP1, the control does not install. It also fails on othermachines (like the customer's machine) but I do not have alist of operating systems or other stats on those machines.
The error message I get is this:

*** Code Download Log entry (09 Nov 2004 @ 11:04:57) ***
Code Download Error: (hr = 800c0300) Unknown Error!!
Operation failed. Detailed Information:
CodeBase:http://kwmqasite2/ocx/KwmActiveXControls.CAB
CLSID: {24959835-9D2A-40AA-B6B2-9BA0905D47F0}
Extension:
Type:

LOG: Item KwmActiveXControls.ocx being processed.
--- Detailed Error Log Follows ---
LOG: Download OnStopBinding called (hrStatus = 0 /
hrResponseHdr = 0).
LOG: Item KwmActiveXControls.ocx being processed.
LOG: Item KSPBCO.dll being processed.
LOG: Item scrrun.dll being processed.
LOG: Item msvcrt.dll being processed.
LOG: Item msxml3.dll being processed.
LOG: Item KSCTL.dll being processed.
LOG: Item winhttp.dll being processed.
ERR: INF Processing: Failed (800c0300) processing:
winhttp.dll. Cannot get primary/default language!LOG: URL
Download Complete: hrStatus:0, hrOSB:800c0300,
hrResponseHdr:0,
URL:(http://kwmqasite2/ocx/KwmActiveXControls.CAB)
LOG: Reporting Code Download Completion: (hr:800c0300
(FAILED), CLASSID: 24959835..., szCODE:
(http://kwmqasite2/ocx/KwmActiveXControls.CAB),
MainType:(null), MainExt:(null))

Researching this on Google does not reveal a heck of a
lot. This issue seems to be common and no one has
discovered the underlying cause or a solution.

Grasping at straws, I put together a table of the dlls in
the log and the versions.

DLL .cab file Windows 2000 Windows XP
(succeeded) (failed)
scrrun 5.6.0.6626 5.6.0.6626 5.6.0.6626
msvcrt 6.1.9844.0 6.1.9844.0 7.0.2600.1106
msxml3 8.30.9926.0 8.30.9926.0 8.30.9926.0
winhttp 5.1.2600.1327 5.1.2600.1327 5.1.2600.1108

The log says that the problem is winhttp.dll. This may ormay not be the issue. The only difference I can see is
that the version number is different on the client machinewhere it failed. Then again, the msvcrt also has a
different version number, albeit a later one.

Could the problem be the version number? Or is it
something else. No one seems to have an answer to this
and I am hoping someone on this board has some brilliant
insight.

Thanks.


.