PDA

View Full Version : InstallShield 11 problem (wrong forum, I know) - Upgrade issue - please help me



MikeAshton
01-13-2010, 12:25 PM
Sorry for posting in the wrong forum. There doesn't appear to be an InstallShield 11 forum any where.

Anyway, somebody has left my company and I'm left with InstallShield so I'm new to all this.

I have recently tried to produce a new install (a minor upgrade). A clean install works correctly, but when I try to perform an upgrade of an older version of our software InstallShield just goes through the motions; it updates the Add/Remove Programs list but fails to copy any files.

I thought this was my ineptitude at modifying the install, so I did a "get" of a previous install and rebuilt it. My rebuilt version exhibits the same functionality, clean installs work, but upgrade do not copy any files (the original version built by the guy who has left works correctly).

Any ideas where I can start looking? I have tried producing an MSI log, but there is just too much information in there. I'm not sure what to look for. Have there been any Windows/Flexera updates which could have affected the functionality?

Any help would be greatly appreciated.

Thanks
Mike.

Cary R
01-13-2010, 01:40 PM
Hi Mike,

I would try the following KB, as it's a great start on troubleshooting issues like this:

Q200372: Troubleshooting Minor Upgrades
http://kb.flexerasoftware.com/selfservice/viewContent.do?externalId=Q200372

Let us know what you find.

--Cary

MikeAshton
01-14-2010, 01:02 PM
Hey thanks for the link, it was very useful.

I've been through the webpage and using my limited understanding of InstallShield I _think_ I might have got to the bottom of the issue. Maybe.

Let me run it by you...

When I attempt the upgrade the MSI log states:
ComponentId '{9BFFB8F8-F55F-10B2-C01F-C8B3B9A1E18E}' is registered to feature 'Required', but is not present in the Component table. Removal of components from a feature is not supported!

It's the "Required" feature which is not being installed. So... tracing this back to the installation which is being upgraded the GUID relates to:

MSI (s) (60:8C) [10:00:09:400]: Executing op: ComponentRegister(ComponentId={9BFFB8F8-F55F-10B2-C01F-C8B3B9A1E18E},KeyPath=02:\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Installations\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\downlevel_manifest.8.0.50727.762

I know that Microsoft have recently upgraded the runtime (to 507272.4053). When I look at the redistributables which are included my new install it is picking up the 4053 (presumably from C:\Program Files\Common Files\Merge Modules)?

Does this sound reasonable? If I am correct in my assumption, what can I do?

Thanks
Mike.

MikeAshton
01-18-2010, 04:51 AM
I found this website from (what appears to be) a Microsoft employee.

http://blogs.msdn.com/msiclickonce/archive/2009/09/09/using-msm-from-security-update-971090-and-973673-as-prerequisite-to-create-msi-minor-update-would-not-work.aspx

I'm currently working through his workarounds.

Cheers,
Mike.

MikeAshton
01-18-2010, 07:16 AM
For anybody else who may be experiencing this issue, check out the following website:

http://blogs.msdn.com/msiclickonce/archive/2009/09/09/using-msm-from-security-update-971090-and-973673-as-prerequisite-to-create-msi-minor-update-would-not-work.aspx

Cheers
Mike.

firmusoft
11-11-2011, 12:10 AM
For anybody else who may be experiencing this issue, check out the following website:

http://blogs.msdn.com/msiclickonce/archive/2009/09/09/using-msm-from-security-update-971090-and-973673-as-prerequisite-to-create-msi-minor-update-would-not-work.aspx

Cheers
Mike.

mike just wanted to know if the workaround worked for you.

I was not able to understand the workaround mentioned there. Did he mean to include the redistributable in the project and then run it from a custom action? In that case, why would we need the merge modules as well ?

Also didnt quite get what he meant by "InstallShiled does direct linking and would pick the latest version of the merge module build from the machine". The MMs are included in the generated installs at build time, right?

MikeAshton
11-11-2011, 04:27 AM
Hi,

The workaround worked for me. As I said in my first e-mail I'm not the most experienced InstallShielder, but I'll try to explain.

I ended up creating the fake components in my MSI file which matched the components which Microsoft removed from their merge module. This meant that I had 6 or 7 new components which didn't really do anything for my installer (except satisfy the installer service which no longer thought that component had been removed i.e. they were moved from the Microsoft MSM into my MSI).

The direct linking comment refers to the fact that when MSI installs a new program it keeps a copy of the latest version of the merge modules in a local folder.

In the case of the runtime this means that any software which installs the later (broken) version of the runtime merge module will replace the "good" copy (which was used to build the previous "good" installer) with the "broken" copy. When you subsequently re-build the installation package InstallShield will pick up the runtime from the shared folder, except this time the runtime is the broken version.

As I recall there was no need for a custom action.

I hope this makes some sense.

Thanks
Mike.