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

Comments

Please log in to comment

Community Chosen Answer

1
Perhaps there's an AppSearch taking place and populating the INSTALLDIR property?

As ever, a verbose log of the install will be worthwhile.
Answered 03/11/2008 by: VBScab
Red Belt

Please log in to comment
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

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.
Answered 03/11/2008 by: reds4eva
Second Degree Blue Belt

Please log in to comment
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.
Answered 03/11/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
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.
Answered 03/12/2008 by: MicrosoftBob
Blue Belt

Please log in to comment
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?
Answered 03/12/2008 by: MicrosoftBob
Blue Belt

Please log in to comment
0
Hi Bob,
did you check the ODBC... tables for unwanted entries?
Regards, Nick
Answered 03/12/2008 by: nheim
Tenth Degree Black Belt

Please log in to comment
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).
Answered 03/13/2008 by: VBScab
Red Belt

Please log in to comment
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. [;)]
Answered 03/17/2008 by: MicrosoftBob
Blue Belt

Please log in to comment
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
Answered 03/18/2008 by: spartacus
Black Belt

Please log in to comment
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.
Answered 03/18/2008 by: AngelD
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity