4 replies to this topic

[overlord]

If I re-run my installer multiple times it errors out with a file lock on the temp folder it is extracting to. Is there a way to have it extract to a different folder every time or is there any work around for this issue?

[deramor]

I believe the folder it extracts to is a GUID that is equal to either you package code or product code.  Neither can be changed after you build your installer.

 

Do you execute anything out of this temp folder?  I've never seen this kind of behavior before.  If you are executing something from this folder, you may want to launch the file from a unique folder name.  .Net can provide you with a folder that is supposed to be unique.  You could do something like that in a custom action to copy the files from your current temp folder and into another one before launching.  Take care to clean up this new folder yourself however.

 

It may also be possible that there isn't enough time between install process launches to clean up after the install that just exited.  If you didn't need the files, you could do a custom action that deleted the folder when your installer exited.  I believe there is a predefined constant with the GUID in it.

[overlord]

I thought that too but it didnt seem to match up against any of the GUID codes when I looked. Ill check again in the am when I am back at the office. It is the first time I have really encountered anything like this. I also checked the msi log file and it was less than helpful. Ill see if i can find anything worth posting from it tomorrow.

[overlord]

ok, I checked %TEMP% while extracting. the bootstrapper exe file consistently extracts to the same folder per version of the installer. Inside there is a config file with a variable in it called TEMPPATHGUID=insertguidhere

every time it extracts it extracts to this folder. The msi on the other hand gets dumped into a seemingly random folder every time. The guid it is using is not tied to any variable in the installer itself. I compared it to the package, product and upgrade code. 

 

So it looks like the problem lies with the bootstrapper aka setup.exe and where it extracts to. Its worth noting that if you wait a few seconds longer the folder disappears and the problem does not persist.

[deramor]

I've seen lengthy post processing times for InstallScript MSI projects but never for basic MSI.  In practice, they have always been rather snappy but then I'm not executing the same installer many times programmatically.  Would a delay be helpful/possible?