0

I am writing my first WIX installer. The installed application uses various Microsoft standard OCX controls which are installed as merge modules, for example MSCOMCTL.msm, MSFLXGRD.MSM etc.

For some reason, if the target machine has UAC switched on, running the application after installation fails with a message to the effect that "MSCOMCTL is missing or has not been correctly registered...". However, if the application is run once 'As Administrator' it puts up a UAC "can this app make changes" message (so it's obviously changing something) and then runs fine, and what is more runs forever after without admin privs. (Alternatively, registering the relevant controls with RegSrv works as well).

I have monitored the application with ProcMon and it is obviously doing a late registration. It is as if the installer has advertised the contents of the merge module without installing them. I've also looked at the merge module, and my MSI, with Orca, but I can't work out any way of stopping this behavior.

I did wonder if it was anything to do with the versions of the MSMs, but it seems almost impossible to find out what the latest version of these Microsoft MSMs is, or to find anywhere to download them.

Obviously we do not want to make our customers go through this convoluted process when they install our product. Any suggestions would be greatly appreciated.

Dave
  • 3,429
  • 2
  • 26
  • 29
  • Have you made sure that the feature with which the merge module files are associated, is not advertised? Also, is it an advertised shortcut? Take a look at: https://msdn.microsoft.com/en-us/library/windows/desktop/aa367548(v=vs.85).aspx. Also, from your description of the problem, it seems like your application needs administrative privileges to run. If so, you should mark the user as requiring administrative privileges so that the user is prompted for elevation, right at the time of installation. If you could share the merge module or provide me a location from where i could download them, – Kiran Hegde Aug 21 '15 at 05:55
  • i can try it in a sample project and see the behavior. – Kiran Hegde Aug 21 '15 at 06:00
  • I tried putting AllowAdvertise="no" on the containing feature, but that made no difference at all. The feature itself is not advertised, not are the shortcuts, in fact nothing in the kit is advertised, at least not intentionally. The application certainly does NOT require admin privileges. It has run fine for many years (using an InstallShield kit), and as I stated, after it has been run once 'As Administrator' thereafter it runs fine with normal privs. – Dave Aug 21 '15 at 12:22
  • Is it possible for you to upload a log file? – Kiran Hegde Aug 21 '15 at 12:25
  • Kiran, yes, thanks for taking the time. You can get the log file at www.knoware.co.uk/Product_20150819121644_0_ProductInstall.zip – Dave Aug 23 '15 at 12:48
  • So it turns out that you can actually advertise just the COM registration information without having to actually advertise the entire feature tree. Take a look at the Wix documentation for the tags: TypeLib,Class, ProgId. Each of these tags has an Advertise attribute which i believe is resulting in a behavior that you are seeing. Further, reading the description of the Class table on MSDN, i see the following:The Class table contains COM server-related information that must be generated as a part of the product advertisement. Do you see tables such as Class and ProgId in your msi package? – Kiran Hegde Aug 27 '15 at 05:55
  • I also came across a project of mine where i had done something similar without the main feature being advertised. You could probably run the tool: ProcessMonitor and see the registry keys which are being advertised upon first installation. – Kiran Hegde Aug 27 '15 at 05:56
  • Were you able to determine the root cause? – Kiran Hegde Aug 31 '15 at 07:50

1 Answers1

1

Thanks Kiran. We also read that bit in the MSDN documentation. The problem is that we can't alter the Advertise attributes on items that are already built into Microsoft's Merge Modules (well, we could using Orca but it would be messy).

However, I think we may have found the source of the problem. The previous release of our product used a kit built using InstallShield. When we compared the .MSI created by InstallShield to the one created with Wix we noticed that the InstallExecuteSequence table of the IS one contains RegisterProgIdInfo, RegisterClassInfo and RegisterTypeLibraries, which do not appear in the Wix-generated MSI. We think some or all of these may be needed to force the MSMs to install. I need to find out how to put these into Wix, and then to try it to see if it works. I will try to remember to post the result here for posterity.

[Following day] Confirmed. For anyone else who has this problem, you just need to put a <RegisterClassInfo/> tag and a <RegisterProgIdInfo/> tag (and maybe a <RegisterClassLibraries/> tag, but I didn't need one of those) into your <InstallExecuteSequence>.

Dave
  • 3,429
  • 2
  • 26
  • 29