6 replies to this topic

[Superfreak3]

I'm working with my web setup, trying to get the files to go to a destination of the user's choosing other than wwwroot. I was testing, but not getting much results, so I reverted back to a working copy of my .wsi pulled from our safe.

I put this in place, deleted the existing, test .msi then recompiled. After running, my files were literally placed in a C:\[INSTALLDIR] directory on my test machine. This is what was happening in my test scenario.

I then thought that maybe I 'corrupted' my safe version with a test version so I tried this new .msi on another machine and it worked as intended with the files being placed in wwwroot.

I remember, way back in the day, when working with .msi, sometimes there is a cache copy hanging somehow and that is what was actually running instead of any changed .msi for test. So, at times, it seemed that any changes were not taking effect when in fact an older package was running.

I've tried removing my app. along with the .msi and even the template, then searched the registry for any remaining items associated with my app, but found nothing. Now this could mean I don't know what to look for. I even tried searching for the reversed product code, but found nothing after app. removal.

Does anyone have any ideas of what might be going on here?

Any help would be greatly appreciated.

[Glytzhkof]

There is probably a cached copy of your setup with the same package code in C:\Windows\Installer. Compile a new version of your setup with new package and product codes and try again.

[Glytzhkof]

Or just change the package code, that should be sufficient - depends if you want to do minor upgrades later on (I generally find major upgrades more reliable and hence I change the product code in every package build and then author the Upgrade table with the necessary entries to run a major upgrade).

[Vijay_k]

Yes, this problem is there because of the cached copy. As mentioned in above comment, it is present in C:\Windows\Installer
There will be unique naming convention used for each application. Sort the files by date and you will get your MSI in the last.
Either delete this file and then try to install the new version of the file.
Or
Replace that old file from the location C:\Windows\Installer with the new file, remember to keep the same name for this file to.
Now try to continue testing installation\uninstallation. It will work.
------ Vijay

[Glytzhkof]

I wouldn't recommend replacing files in the C:\Windows\Installer folder. It is better to change the package code in the MSI file and then run the file again. Then msiexec will not look for a cached copy in C:\Windows\Installer. If you want you can locate the cached MSI in this folder, right click it and select uninstall and finally delete the file (show the statusbar in explorer and the name of the msi will show up in the bar), but don't replace the existing file with a new one!

[Superfreak3]

Here's what I did to jump this hurdle.

I tried everything, believe me. I did check in Windows\Installer, but couldn't find my installation package.

Well, here's what worked for me....

I ensured that the application with the problematic file placement was removed from the system. Then, I executed msiexec /I [path to updated msi file] REINSTALL=ALL REINSTALLMODE=vamus from the command line.

The install appeared to fire, but it seemed to indicate success fairly quickly and it didn't seem like anything was installed. So, due to curiosity, I simply executed the .msi, this time from my build directory. Everything from that point seems OK as the installation is now 'behaving' as intended.

The install log, which previously showed references to C:\[INSTALLDIR]\, now contained none of these problematic references.

Huh.

I'm sure glad that's over with (for now)!!!

[Stefan Krueger]