Vista major upgrade issue

[Reinyn]

Hello,

We have a product that we are deploying on XP and Vista. Our first Vista compatible release was 8.0 and now we are testing 9.0. On XP the major upgrade works fine.

On Vista the installation succeeds, but when the application is executed we get the "Please wait while windows configures your application". This dialog fails presumably because it is looking for a .msi package and we are deploying a single Setup.exe. Another annoyance is that we are stuck in a endless loop here. Canceling the dialog just launches the app again which brings up the dialog.

Performing a clean install (remove the 8.0 version first) works fine on Vista.

The event viewer has the following entry.
Event 1004, MsiInstaller
Detection of product '{B4062CCD-0A00-444E-8B4F-680CDBE5D13D}', feature 'AlwaysInstall', component '{97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E}' failed. The resource '' does not exist.

If I look for that guid in the install log I find these entries.
-----------------------------------------------------------------------
MSI (c) (E4:74) [15:19:37:403]: skipping installation of assembly component: {97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E} since the assembly already exists

MSI (s) (C8:30) [15:20:04:003]: skipping installation of assembly component: {97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E} since the assembly already exists

MSI (s) (C8:54) [15:20:31:473]: Executing op: ComponentUnregister(ComponentId={97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E},,BinaryType=0,)

MSI (s) (C8:54) [15:20:56:108]: Executing op: FileRemove(,FileName=ATL80.dll,,ComponentId={97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E})

MSI (s) (C8:54) [15:20:56:138]: Executing op: FileRemove(,FileName=x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_cbb27474.cat,,ComponentId={97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E})

MSI (s) (C8:30) [15:21:27:458]: Executing op: ComponentRegister(ComponentId={97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E},KeyPath=>ATL80.dll\Microsoft.VC80.ATL,type="win32",version="8.0.50727.762",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)

MSI (s) (C8:30) [15:22:17:322]: Executing op: AssemblyPublish(Feature=AlwaysInstall,Component={97F81AF1-0E47-DC99-A01F-C8B3B9A1E18E},AssemblyType=2,,AssemblyName=Microsoft.VC80.ATL,type="win32",version="8.0.50727.762",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",)
----------------------------------

So it looks like something screwy is going on with the ATL80 merge module. I tried installing the merge module to the default location as well as locally in the app's install folder. The module doesn't seem like it ever installs locally.

Rename instlogtxt.asl instlogtxt.txt to view it since it was abolve the 2mb limit.

[Reinyn]

BUMP: Any Ideas?

I set a prerequisite for the MSI 4.5 installer, but that didn't help either.

Am I seeing a manifestation of this problem?
http://support.microsoft.com/?kbid=905238
Does anyone know if this has been addressed in Vista SP1? I am testing the installs on Vista Business and for some reason windows update isn't seeing Vista SP1 yet.

Is there a way to make the merge modules permanently installed?

[hsteinbeck]

check my post out. see if that is similar to your problem
http://community.acresso.com/showthread.php?t=176078

[Reinyn]

I would say that the problems are definitely related.

Can you go into more detail about your solution?

This post seems helpfull, but I'm not actually sure what I need to do with InstallShield to make this work.

By resequencing RemoveExistingProducts after InstallFinalize, the old product is not uninstalled until after the new product is installed. Since the new product is installed first, all of the files are still present on the machine and are ref counted which then prevents ones with ref counts greater than one from being uninstalled when RemoveExistingProducts runs. Running RemoveExistingProducts prior to CostFinalize has the effect of removing the old product before the new one is costed, which eliminates the original problem. You could take either approach; in general we typically recommend sequencing after InstallFinalize since that can be done through a setting in the Upgrades view. In either case, we would recommend testing the setup thoroughly to ensure there aren't any significant issues encountered.

[hsteinbeck]

Sorry for taking so long to reply,

We used orca to modify the merge modules from Microsoft. In the component table we modified the attribute of filed each component installed on Vista, the ones labeled "uplevel". We added the bit flag that would set the component to be permanent, msidbComponentAttributesPermanent, (see help for component table).

Now when a major upgrade is performed on our last release we will not loose our VC80 components. There is one rub, unfortunately, this "fix" applies to this release and later. Upgrading earlier releases will still have this problem because the components are already installed with their original attributes.