9 replies to this topic

[InstallDev]

hi all,

I am creating an msi package using Installshield 9. My problem is that when I run my msi package. a copy of the msi is created in the temp directory with a weired name. This msi never get deleted when the installation is finished. not even after a reboot.....
I understood that this package is created by the windows installer at the begining of the installationt (it is path is stored in the DATABASE property).

I did try to install some other msi applications. This weired-named msi package are created but they always get deleted when the installation is finished.
I searched the forums here and in installshield website for any possible reasons. but it seems like no one is having this problem. And those who have it, they fixed it by just rebooting thier systems.

I don't know what I am doing wrong that prevent the windows installer from deleting it.

How can I tell the installer to clean that file... If the windows installer can't delete it. Is it safe to delete this file at the end of the installation in the last CA of my Execute sequence?

Note: this msi file is not the only one... all the language mst files are also there and they never get deleted.

Thank you....

[InstallDev]

hi all,

No one is encountring the same problem???? Am I alone???

Any help is appreciated..

Thank you all

[luke_s]

All of my temporary msi files are removed when i install. Try looking at the permissions on the temp directory.
Maybe try running the install with verbose logging, this might say something about the temp file and why it does not delete it.

[InstallDev]

Hi,

I searched the log file for any entry of that temp msi file.....
The only one is here......

MSI © (70:44): End dialog not enabled
MSI © (70:44): Original package ==> C:\DOCUME~1\ferasa\LOCALS~1\Temp\~exb0000773163265\MyProduct.msi
MSI © (70:44): Package we're running from ==> C:\DOCUME~1\ferasa\LOCALS~1\Temp\2e17df45.msi
MSI © (70:44): APPCOMPAT: looking for appcompat database entry with ProductCode '{29C990B8-3162-44DD-8146-2EB0FF7C41BD}'.

I can't see how this file must be deleted... Can u please tell me if you have a delete entry in your log file for that msi file.... Who is responsible for this file. Is it installshield setup.exe or the windows installer...... it seems like windows installer

Thank you

[InstallDev]

Hi,
There are two files that don't get deleted one of them is the .msi and the other is .mst (For the language). I have found the following at the last end my log file....

Property©: ALLUSERS = 1
=== Logging stopped: 5/28/2004 8:45:41 ===
MSI © (BC:C4): Note: 1: 1707
MSI © (BC:C4): Product: MyProduct -- Installation operation completed successfully.

MSI © (BC:C4): Attempting to delete file c:\DOCUME~1\ferasa\LOCALS~1\Temp\6b52c.mst
MSI © (BC:C4): Unable to delete the file. LastError = 32
MSI © (BC:C4): Grabbed execution mutex.
MSI © (BC:C4): Cleaning up uninstalled install packages, if any exist
MSI © (BC:C4): MainEngineThread is returning 0
=== Verbose logging stopped: 5/28/2004 8:45:41 ===


error 32 means that the file is being used by another process. Someone is using the mst ... I can't see anyone except the windows installer itself.. I looked at the task manager it seems like there are 4 running msiexec at some point during the installation. 1 System process and 2 user processes during UI. And one user process that get's generated during the execute sequence..... All 3 user process will go away at the end of installation. The system process will stay there. I read somewhere that this is normal.... I am not sure anymore..

One more thing that could be the cause
I have a check box at the end of dialog to launch my application. when the user click finish it fires my installed application. (CA doen't wait for it to finish, doesn't ignore the result,,,,, I tried also to ignore the result) I am not sure if that would stop the installer from deleting the msi files..

Do you see why I am not able to delete these files.........

Please,,,, please if you have any idea, please share it...
Thank you all

[luke_s]

The extra process running at the end of the install is the msi server, this is normal.

The error 32 is definetly the problem. The mst file is a transform isnt it? Is this generated by install shield for your languages?

I am not to sure where to head with this problem. Maybe you could try searching the install shield knowledge base, searching the forumns or logging an issue with install shield.

[InstallDev]

Hi,

Sorry for being late.....
Yes the mst is the language tranform generated by installshield.
I did search their knowledge base and community but with no success at all.....
It is either I don't have the skills to do a good search ,,, or i am the only one with this problem>>>>

Thank you all

[Glytzhkof]

Windows Installer first caches a copy of the MSI database in TEMP, then as it switches from the client process to the server process (that is once the InstallExecuteSequence starts running) the database should be copied to [SYS32]\Installer\randomname.msi and start running from this location. Are you doing anything special in the user interface before reaching the ExecuteAction standar action? Things such as accessing COM servers, writing files, etc...?

[gloom]

to InstallDev
You are not alone I have the same problem.
to Glytzhkof
!!! Thanks for your reply! That's the point!
Yes, I'm copying files. One CA replace old files to .bak files. The next CA delete old index files .mdx from folder. Also I'm installing MDAC. Moreover I copy and register atl.dll...
All these actions I do in User Interface before ExecuteAction.
Therefore the aforesaid processes are not finished in time (before ExecuteAction) - it's the cause, isn't it??

[Glytzhkof]

Running processes would certainly cause the MSI file not to be deleted. If you have any asynchronous custom actions the setup will not wait for them to complete before continuing, you could check that all these actions are running synchronously.

However, I believe there is a general problem with your approach: these actions running in the user interface sequence will never be run if the setup is installed silently (since the whole user interface sequence is skipped). If you move all the actions you mention to the InstallExecute sequence they will be run with a silent install, and the MSI file in TEMP should be removed correctly (since the actions are not run while the database is running from this location). You may however still have the same problem with the MSI file cached in [WINDIR]\Installer\ not being removed correctly during uninstalling (because there may still be hanging processes).

About the custom actions:

1: One CA replace old files to .bak files.
-> Should be fine as long as the custom action is run synchronously

2: The next CA delete old index files .mdx from folder.
-> Should also be fine, same as above

3: Also I'm installing MDAC.
-> I am not familiar with this issue, but if there is a merge module for MDAC you should use it instead of running the MDAC setup yourself

4: Moreover I copy and register atl.dll...
-> This sounds strange. This file may be on the protected list for Windows. You are probably updating this file since you also install some COM automation components? There must be a regular merge module somewhere to install this file correctly. If not you could try installing it to the application directory. I would NOT copy this file to the system folder without checking it more.