1 reply to this topic

[cculler]

I have an ActiveX control (ocx), written in VB6 by someone else, that bundles up nicely with Package and Deployment Wizard (PDW). Now I'm forced (apparently) to bundle it up in an MSI or MSM, and I can't seem to make it work.

I have available the following tools: Visual Studio 6, Visual Studio .NET (1.0), the latest Windows Platform SDK (includes Orca and other neat toys), and Visual Studio Installer.

Here's the background:

Up until recently, the ActiveX control was deployed via CAB for use on a web page. Packaging requirements now include MSSoap3, and the only way to include MSSoap3 is via merge module and an MSI. I have managed to accomplish this by including a Soap3/XML4 MSI within my CAB file and tweaking the .INF file to also run the included MSI. It works, but it's not pretty. More importantly, it shows up on the target system as two separate installs (one for the MSI and one for the OCX). This, I believe, goes against the licensing agreement for redistribution of the Soap merge modules.

If I'm not mistaken, if I can figure out how to install the ActiveX control via MSI/MSM, I can effectively deploy this whole mess as one cohesive package and be done with it.

Any tips would be hugely appreciated.

[Stefan Krueger]

In VS.NET (has Visual Studio Installer built in) create a Deployment project (e.g. inside the solution that creates the ActiveX control). Add your ActiveX (resp. the project output), and the soaü merge module. Build.