/build/static/layout/Breadcrumb_cap_w.png

Package does not install in same folder on all computers

I have created a package for software called Remedy via a Wise snapshot. The install dir and default dir is set to C:\Program Files\Remedy7.1. However, when I pushed it out to 250 computers, about a third of them installed the application into C:\Program Files\Remedy, the location of the old version which was installed previously (looks like another packagers MSI, with different GUID).

How and why did it pick up the other installation folder?

[8|]

0 Comments   [ + ] Show comments

Answers (10)

Posted by: anonymous_9363 12 years ago
Red Belt
1
Perhaps there's an AppSearch taking place and populating the INSTALLDIR property?

As ever, a verbose log of the install will be worthwhile.
Posted by: anonymous_9363 12 years ago
Red Belt
1
ORIGINAL: nheim
did you check the ODBC... tables for unwanted entries?
If the OP wasn't already aware, this is yet another standing instruction for Wise users: always convert ODBC table entries to straight registry entries. I can't think of a single occasion when Wise has done ODBC properly for me (and I always try, with each new release).
Posted by: reds4eva 12 years ago
Second Degree Blue Belt
0
Im not sure why the installdir is not created, Im guessing that it has something to do with the old version not being removed, files in use or something, maybe.
Add the upgrade code of the old version so it removes it before it installs the new version.
Posted by: jmcfadyen 12 years ago
5th Degree Black Belt
0
Im guessing you have upgrade table already configured but not the same as reds4eva has suggested. if the uninstall is not done first you can see this behaviour.
Posted by: MicrosoftBob 12 years ago
Blue Belt
0
Ok, first, my package has nothing to do with the previous version package. This is not (supposed to be) an upgrade.

Also, I found a computer that has the previous version installed manually via a non-MSI Installshield setup, and my package still installed in the wrong path.

Below is a relevant portion of the log (I keep forgetting about the log option). It appears the custom action WisePreparePathConversion is changing the value of InstallDir. Does this action automatically get added during a snapshot? Why and how is it finding the old version of the software and changing the Installation path? Can I just delete this action without problems?


MSI (s) (B0:88) [10:26:42:537]: Doing action: WisePreparePathConversion
Action ended 10:26:42: CostFinalize. Return value 1.
MSI (s) (B0:88) [10:26:42:553]: Creating MSIHANDLE (40) of type 790542 for thread 904
MSI (s) (B0:64) [10:26:42:553]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI9F7.tmp, Entrypoint: PreparePathConversion
MSI (s) (B0:44) [10:26:42:553]: Generating random cookie.
MSI (s) (B0:44) [10:26:42:553]: Created Custom Action Server with PID 3692 (0xE6C).
MSI (s) (B0:3C) [10:26:42:631]: Running as a service.
MSI (s) (B0:3C) [10:26:42:631]: Hello, I'm your 32bit Impersonated custom action server.
MSI (s) (B0!BC) [10:26:42:693]: Creating MSIHANDLE (41) of type 790541 for thread 3260
MSI (s) (B0!BC) [10:26:42:693]: Creating MSIHANDLE (42) of type 790540 for thread 3260
.
.
.
MSI (s) (B0!BC) [10:26:42:897]: Closing MSIHANDLE (79) of type 790531 for thread 3260
MSI (s) (B0!BC) [10:26:42:897]: Closing MSIHANDLE (78) of type 790540 for thread 3260
MSI (s) (B0!BC) [10:26:42:897]: PROPERTY CHANGE: Adding WiseConvertPaths property. Its value is 'C:\WINDOWS\TEMP\wpr9F8.tmp'.
MSI (s) (B0!BC) [10:26:42:897]: Closing MSIHANDLE (41) of type 790541 for thread 3260
MSI (s) (B0:64) [10:26:42:897]: Closing MSIHANDLE (40) of type 790542 for thread 904
Action start 10:26:42: WisePreparePathConversion.
MSI (s) (B0:88) [10:26:42:897]: Doing action: SetODBCFolders
Action ended 10:26:42: WisePreparePathConversion. Return value 1.
MSI (s) (B0:88) [10:26:42:897]: LocalSQLInstallDriverEx returned 1 in remote context.
Action start 10:26:42: SetODBCFolders.
MSI (s) (B0:88) [10:26:42:897]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038
MSI (s) (B0:88) [10:26:42:897]: Note: 1: 2262 2: BindImage 3: -2147287038
MSI (s) (B0:88) [10:26:42:897]: PROPERTY CHANGE: Modifying INSTALLDIR property. Its current value is 'C:\Program Files\Remedy7.1\'. Its new value: 'C:\Program Files\Remedy\'.
MSI (s) (B0:88) [10:26:42:897]: PROPERTY CHANGE: Modifying ARCmds property. Its current value is 'C:\Program Files\Remedy7.1\ARCmds\'. Its new value: 'C:\Program Files\Remedy\ARCmds\'.
MSI (s) (B0:88) [10:26:42:897]: PROPERTY CHANGE: Modifying lib property. Its current value is 'C:\Program Files\Remedy7.1\lib\'. Its new value: 'C:\Program Files\Remedy\lib\'.
MSI (s) (B0:88) [10:26:42:897]: PROPERTY CHANGE: Modifying images property. Its current value is 'C:\Program Files\Remedy7.1\images\'. Its new value: 'C:\Program Files\Remedy\images\'.
MSI (s) (B0:88) [10:26:42:897]: PROPERTY CHANGE: Modifying License_Agreements property. Its current value is 'C:\Program Files\Remedy7.1\License Agreements\'. Its new value: 'C:\Program Files\Remedy\License Agreements\'.
MSI (s) (B0:88) [10:26:42:897]: PROPERTY CHANGE: Modifying resdlls property. Its current value is 'C:\Program Files\Remedy7.1\resdlls\'. Its new value: 'C:\Program Files\Remedy\resdlls\'.
MSI (s) (B0:88) [10:26:42:897]: PROPERTY CHANGE: Modifying _0009 property. Its current value is 'C:\Program Files\Remedy7.1\resdlls\0009\'. Its new value: 'C:\Program Files\Remedy\resdlls\0009\'.
MSI (s) (B0:88) [10:26:42:897]: INSTALLDIR folder has been set to 'C:\Program Files\Remedy\'
MSI (s) (B0:88) [10:26:42:897]: Note: 1: 2262 2: ODBCTranslator 3: -2147287038
MSI (s) (B0:88) [10:26:42:897]: Doing action: MigrateFeatureStates
Action ended 10:26:42: SetODBCFolders. Return value 1.
Posted by: MicrosoftBob 12 years ago
Blue Belt
0
New info....the SetODBCFolders is causing the InstallDir change, not WisePreparePathConversion.

I commented out this action and it works ok now.

I hope this won't cause other problems in my install....anyone have any insight on that?
Posted by: nheim 12 years ago
10th Degree Black Belt
0
Hi Bob,
did you check the ODBC... tables for unwanted entries?
Regards, Nick
Posted by: MicrosoftBob 12 years ago
Blue Belt
0
Nick:

Checked the ODBC and there are no unwanted ODBC entries.


Ian:

Removing the SetODBCFolders action appeared to cause an error on at least one of the clients so I took your advice and convert the ODBC stuff into registry entries.



Thanks to all for the help. [;)]
Posted by: spartacus 12 years ago
Black Belt
0

If the OP wasn't already aware, this is yet another standing instruction for Wise users: always convert ODBC table entries to straight registry entries. I can't think of a single occasion when Wise has done ODBC properly for me (and I always try, with each new release).



I'd endorse this approach for InstallShield users as well, FWIW.

Spartacus
Posted by: AngelD 12 years ago
Red Belt
0
I do agree with Spartacus here.
If I recall Windows Installer ODBC related tables only support Microsoft ODBCs so to be sure use the Registry table instead.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ