Software Deployment

MSCOMCTL.OCX is itself an ActiveX control (as the name suggests, it deal with a set of COMmon ConTroLs) and doesn't affect whether or not other ActiveX controls can be installed or not.

To be a total pedant, it would most unlikely that a deployment would modify the file: it would replace it. 'Modify' implies a patching process of some kind.

This application actually needs client side server connectivity,and we are not able to replicate the error here at our side.What difference we found between setup.exe and package is only this ocx is getting modified, as per Installrite,and the application is showing ERROR:429 when shortcut is launched.(Error Description : ActiveX component cannot create object).

Will it be better if we register the ocx and then add it to package?

Thanks...

InstallRite is showing it as modified because, in all likelihood, the version info has changed as well as the date and time stamp. It will have been replaced.

No offence, but I suggest you change your moniker here at AppDeploy because, if you don't understand ActiveX - and you clearly don't - you cannot reasonably call yourself a packager. That is further evidenced by your thinking that registering the OCX on your packaging machine before adding it to a package somehow means that its COM information will get added to the client machine.

Most packaging tools will read COM information from a DLL/OCX and add it to the appropriate MSI tables without the packager's intervention. Failing that, most will have a utility (e.g. WiseComCapture in Wise) to extract that information to a .REG file. On importing that file, the tool will again populate the relevant tables.

Can I suggest you get hold of Phil Wilson's ouevre, The Definitive Guide to Windows Installer? That will give you a good grounding in WI fundamentals. Then you can start packaging.

Try with Gap Capture if you can find some relevant info which is useful :)