Strange repackaged program behaviour

[nikoboivin]

At work, I have to package Visual Studio 6 to run under windows 7 64 bits. I know the product is not supported under windows 7 and it causes the legacy installation to fail when deployed silently. We have tried to convince the analyst to use another method (using thinapp or a virtual windows 7) but were told that since the manual installation worked, we had to make this work for silent deployment.

We managed to manually install it, so we took a clean vm and started repackaging it. Since it included a reboot, we chose the snapshot option in multipe steps.

We managed to capture the installation and the program run fine on the installation machine.

When we deploy the compiled msi on another machine, whenever we start the program, we get a windows installation box telling us "Please wait while windows configure visual studio" before the program opens. This particular box refers to the adminstudio msi, giving us an error if the source path is no longer available.

This will occur everytime a new user tries to open the program. For example, if user A is logged on, working on vs6 and logs off. User B logs in and opens VB6. He gets the configuration dialog. He can then use it as he whishes. He logs off and user A logs in again. User A has to go through the dialog once more.

Any idea on what could be causing this?

[Evan_Border]

It sounds to me like some background noise was captured and was marked as a component key. So whenever somebody fires up the app, the Windows Installer service performs a health check against all component keys* and performs self-healing if any are missing.

*Component keys are not to be confused with registry keys...component keys are sometimes known as "Key Paths" and represent the most important resource in a component. They can be files, folders, registry, or ODBC data sources.

So it's very possible that some unrelated background noise ended up in the package and unfortunately has been flagged as a component key.

What you should do is go into the Control Panel > Administrative Tools > Event Viewer and look at the Application Log. All Windows Installer self-healing will appear in the log. Look for the source "MsiInstaller"

You will find a warning message in the Application Log that spells out exactly which registry value, file, folder, or ODBC data source caused the self-healing to begin. It is very likely that the item does not belong in the package and is merely OS background noise that should have been excluded. It is possible that what you are seeing is basically a tug-of-war match between the Windows Installer and the rest of the Windows OS. There may be a temporary registry value that the OS frequently changes and deletes (perhaps used by something like the Indexing service) that you have included in your package. So the Windows Installer places that registry on your machine and then 45 seconds later the Windows Indexing service decides to delete it. Well this doesn't sit well with the Windows Installer so the next time you open Visual Studio, the Windows Installer service sees that the component "key" has been deleted and it performs self-healing. And then 45 seconds later the Indexing service decides to delete that registry value again, and so on and so on ad infinitum. It's tug-of-war.

[nikoboivin]

Thanks Evan!

The only thing it raises is this file : C:\Windows\ServiceProfiles\LocalService\AppData\Local\FontCache-System.dat

I'll try to remove it from the package and see if it helps.

Nicolas

[nikoboivin]

After deleting the file, everything is working as normal as the unsupported soft possibly can. Thanks a lot for your help!