4

I have an legacy installation from a DotNet 1.1 application (with Visual Studio 2003) that will not deploy the msflxgrd.ocx file on the FIRST installation on Windows 7. If I uninstall the MSI and then run the same MSI again, (and future installations on the same laptop), the msflxgrd.ocx file deploys. At first I suspected that it was a regsvr32 issue, but since there is no file to register, it seems to be more of a deployment issue. I have administrative rights on the machines.

I have links to the MSI logs here:

Is anyone able to help?

Thanks!

Sam
  • 669
  • 1
  • 13
  • 26
  • I tried to read your logs but I got a not found error. You've confused me a little though. You have an OCX file which is a COM server but you say there is no file to register. OCX files always need to be registered. ?? – Christopher Painter Mar 21 '12 at 00:16
  • I seem to have this DLL in my SYSWOW64 directory on Win7SP1. I pulled it into InstallShield and did a Extract COM Data operation on it and sure enough it has COM data. The ProgID is MSFlexGridLib.MSFlexGrid.1 and the description is Microsoft FlexGrid Control, version 6.0. – Christopher Painter Mar 21 '12 at 00:21
  • Sorry, Let me try to clarify. When I run the installation, on a clean machine, the ocx file does NOT get deployed from the MSI to the file system. I can search the entire HD, and it's not there. All the other files are present. If I uninstall, and then run the SAME MSI again, the OCX mysteriously appears where it should and everything seems to work. Does that help? – Sam Mar 21 '12 at 00:24
  • The 1st Log is the first installation, where the OCX is not deployed. The 2nd Log is the second installation, where the OCX IS deployed. I reviewed the logs too, but I don't know much about their internals and was hoping there was an expert here who could help. – Sam Mar 21 '12 at 00:27
  • HTTP Error 404.3 - Not Found The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map. – Christopher Painter Mar 21 '12 at 00:32
  • You can email the logs to chrpai@iswix.com if you'd like. – Christopher Painter Mar 21 '12 at 00:33
  • It's an external IIS server I don't have any control over - which is why I made the HTM page to serve up the files. Regardless, I've just emailed the files over. Thanks for having a look. – Sam Mar 21 '12 at 00:50

2 Answers2

0

From what I see in Log 1, the machine is not as clean as you think. FindRelatedProducts is finding a previous installation of your product and telling RemoveExistingProducts to uninstall it before installing your new version.

I've seen situations when the component rules are violated that MSI thinks a file doesn't need to be installed but the file then gets uninstalled by the removal of the product being upgraded and the file ends up not being installed. By uninstalling and reinstalling you break that up into two steps so that when the second install evaluates the need for the file it comes back as yes and gets installed.

The fact that this is an OCX COM server is just a coincidence and not really relevant to the real problem.

I'd need the MSI already installed and the MSI upgrading to give you specific remedys.

Action start 14:55:44: FindRelatedProducts. MSI (s) (A0:18) [14:55:44:119]: PROPERTY CHANGE: Adding PREVIOUSVERSIONSINSTALLED property. Its value is '{08D8BF6E-E399-4B8A-8B8D-7DFF68F81131}'. MSI (s) (A0:18) [14:55:44:119]: Skipping action: ERRCA_CANCELNEWERVERSION (condition is false) MSI (s) (A0:18) [14:55:44:119]: Doing action: VSDCA_VsdLaunchConditions Action ended 14:55:44: FindRelatedProducts. Return value 1.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Very interesting. I had a look at a 'clean' machine, and couldn't find any evidence of the msflxgrd.ocx file in either the file system or register. Where else might I look? – Sam Mar 21 '12 at 12:21
  • From what I see, that files component was registered for the location "C:\Program Files (x86)\BainApps\HCPD2005". I can see that the file wasn't actually there because MSI didn't schedule a FileRemove operation. But it did unregister ( both COM and MSI metabase ) the component from that location. So to me it looks liek the product had been installed there and something deleted the file. – Christopher Painter Mar 21 '12 at 12:29
  • I use InstallShield and it provides a Merge Module to deploy this control. It has version 6.0.84.18 in it. Does this match what you are trying to deploy? – Christopher Painter Mar 21 '12 at 12:45
0

My previous answer was to explain what was going wrong. This answer will be how to fix it.

InstallShield distributes a Merge Module for this control that contains version 6.0.84.18. However, it seems that this merge module is old and doesn't include a security update that was released by Microsoft a few years back. See the thread:

Updated Merge Modules for MS08-070 Security Bulletin

In the thread Mike Marino tried to get updated merge modules from Microsoft but was told:

Microsoft will not be providing Merge Modules for these. They recommended that users either build their own MSMs or include these files in their own MSIs.

So here is what I would do. Make sure the msflxgrd.dll is the latest version from MS08-070 (6.1.98.14) or newer. Author it into your installer in the SystemFolder directory. Mark it as Permanenet = true. Set the Register attribute to vsdraCOM and set the SharedLegacyFile = true.

Rebuild your installer and test your upgrade scenario again. You should be good to go.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Thank you so much. This was it exactly. I think what happened was that I had to build the MSI on a Windows 7 machine, and had an older version of the OCX that I had when building it on XP, so it messed up the install. Ensuring I had the newest version does the trick - and makes sense too. Thanks! – Sam Mar 21 '12 at 15:46