About Adrien

Adrien · ‎May 09, 2018

Wow, it works like a charm, thank you very much! For those who would have the same need, simply save your Suite Project with a package cache path that you can search easily (ie: [LocalAppDataFolder]Downloaded InstallationsXXX). Then: [LIST=1] Open your .issuite file in a text editor. Search your custom cache path. You will see something like this: [CODE] [/CODE] Update this path as needed (ie: Name="[MyCachePath]"). That's all. If you reopen your Suite Projet, you can see [MyCachePath] as cache path for this package. Nice trick, thanks again 🙂 Adrien

Adrien · ‎May 03, 2018

Hi, Installshield 2018 includes prerequisite for SQL Server 2014 Express SP2. I use this prerequisite in a Suite Project. During the installation of this Suite Project, SQLEXPR_x64_ENU.exe is extracted in %localappdata%\Downloaded Installations\{GUID}. On some machines, probably depending on the length of the Windows account name, the SQLEXPR_x64_ENU.exe installation failed with the following error: SQL Server installation media on a network share or in a custom folder can cause installation failure if the total length of the path exceeds 260 characters. To correct this issue, utilize Net Use functionality or shorten the path name to the SQL Server setup.exe file. (the error is the same when starting the installation outside the Suite Project) To work around this problem, I have to change the cache path of the SQL Server package. I can use: - Other locations like WindowsFolder, CommonDocuments... none of these folders suit me. - A hard-coded value: it's very dirty. - According to the InstallShield help, a formatted expression that contain a property name: perfect, that's what I need! InstallShield help wrote: When you type a value for this setting, you can include one or more formatted expressions that contain property names, environment variable references, and other special strings; at run time, the installation expands the values of these expressions. Unfortunately, when I apply a custom property to the package cache path (ie: [MyProperty]), I get the following error: Invalid path entered. Make sure you enter a valid folder location. So... is there a way to use a property as a cache path, initialized by the user or a custom action? Thanks for help! Adrien

Adrien · ‎Aug 28, 2017

Hi, I remain interested in any opinion about the Cache Path 😉 Adrien

Adrien · ‎Aug 22, 2017

Hi! I currently use some setup.exe packages with Cache MSI Locally option enabled, and default Cache Path ("[LocalAppDataFolder]Downloaded Installations"). As a user folder, this causes a problem if the user who installs the package is not the same as the user who uninstalls it from the ARP (as described in the Installshield knowledge base). To continue using ARP to do this, I plan to move the Cache Path to "[CommonAppDataFolder]Package Cache". I saw that Microsoft was using this folder for some installations (such as Visual C++ packages). From what I know, all users can create subfolders here. In the most common scenarios, users cannot overwrite or remove existing files in this folder if they do not own them, but it is not an issue here (as MSI cache is not removed). Are there any disadvantages to do that? Thanks a lot, Adrien

Adrien · ‎Dec 14, 2015

Hi, I found a very simple trick by using the "Only Remove Specified Features" setting in the advanced tab of the major upgrade item. Features listed in this setting are used in the REMOVE property of the RemoveExistingProducts command line quoted above. By the way, if you specify someting like that: [CODE]ALL CURRENTDIRECTORY="[CURRENTDIRECTORY]"[/CODE] The command line to uninstall the old product in the RemoveExistingProducts action becomes the following: UPGRADINGPRODUCTCODE={GUID} CLIENTUILEVEL=0 REMOVE=ALL CURRENTDIRECTORY="Current directory from your major upgrade" A bit fishy, but it makes the job! Another solution could be to call a small upgrade as a prerequisite before starting the major upgrade, as described here. I haven't tested it, it would have been a little complicated in my case (the previous product had many minor upgrades). Hope this can help! Adrien

Adrien · ‎Dec 14, 2015

Hi everybody, During a major upgrade, the MSI engine call the RemoveExistingProducts action to uninstall the old package with the command line: UPGRADINGPRODUCTCODE={GUID} CLIENTUILEVEL=0 REMOVE=ALL Is there a way to enhance this command line with some custom MSI parameters? I'd like to pass a CURRENTDIRECTORY property, which seems not to be initialized in the old package in this context (it generates an error in one of my old custom action...). I have no problem by uninstalling the old package manually (outside major upgrade, CURRENTDIRECTORY property is well defined). Thanks a lot, Adrien

Adrien · ‎Jun 10, 2015

Hi, In a Suite Project, I use an external dll to validate user inputs in a wizard page. This work fine (although informations about Suite Project dll are not easy to found), but now I want, in some cases, to show warnings on some inputs (example: "Do you really want to do that ? Ok/Cancel"). Unfortunately I don't know how to interpret the modal result of the secondary window. I have tried, in the Next button click of the wizard page: 1- Dll call to validate the inputs - ok 2- Show secondary window to draw a warning if requiered (conditioned by a property affected by the dll) - ok 3- Set active page to the next wizard page if allowed (conditioned by a property affected by the "Ok" click in the secondary window) - don't work I also tried to show message box directly from dll (Delphi), but i recieve EAccessViolation from ISuiteUIExtension.MessageBox. What should I do to show this warnings and check user choices? Thank you in advance, Adrien

Adrien · ‎May 13, 2015

Hi, I received confirmation from Flexera: The Ini file changes view ultimately populates the IniFile table and as the value field takes a data type of formatted, using the syntax of formatted data types such as curly braces would be the proper way to do this. Let's go for curly braces, then! Adrien

Adrien · ‎May 11, 2015

Hi, I'm experiencing a problem with ini files in InstallShield : if I add a new keyword with no value in the ini file change view, or if I import ini file with empty values, InstallShield automatically converts empty values into spaces in the IniFile table. If I remove the space directly in IniFile table, InstallShield restores immediatly. As a result, the product installation initialize ini files with spaces instead of empty values. I want : [IniSection] IniKey= I have (sharp symbolizes a space) : [IniSection] IniKey=# If I upgrade this ini file, regardless the keyword action ("do not overwrite"/"replace old value"), I get a new space : [IniSection] IniKey=## And so on... To counter this, I've tried to replace empty values in the ini file change view with curly braces ( {} ), as we can do in "set property" custom actions (MSI type number 51) to clear a property. Curly braces appear correctly in the IniFile table, and I have the expected result when installing the product (empty values). Is this the right way to do this? Thank you in advance, Adrien

Adrien · ‎Nov 05, 2013

Hi, I have solved the problem by building the Environment table in a custom action. So I can directly add the path without delimiter, instead of using a formatted property in the Value field of the Environment table (which seems to automatically add a delimiter...). in my case (custom action based on a Delphi dll function) it looks like this: [CODE]procedure InitEnvironmentTable(hInstall: MSIHandle); var Db, View: MSIHandle; Path, Query: string; begin if bsMsiGetProperty(hInstall, 'MYPATH', Path, MAX_PATH) then begin Path := ExcludeTrailingPathDelimiter(Path); MsiLogStringFmt(hInstall, 'Adding MYPATH to Environment table... (%s)', [Path]); Db := MsiGetActiveDatabase(hInstall); if Db <> 0 then try Query := 'INSERT INTO `Environment` (`Environment`, `Name`, `Value`, `Component_`) ' + 'VALUES (''NewEnvString'', ''*=-MyEnvString'', ''' + Path + ''', ''MyComponent'') TEMPORARY'; try if MsiDatabaseOpenView(Db, PAnsiChar(Query), View) <> ERROR_SUCCESS then MsiLogString(hInstall, MsiGetLastErrorRecord) else if MsiViewExecute(View, 0) <> ERROR_SUCCESS then MsiLogString(hInstall, MsiGetLastErrorRecord) else MsiLogString(hInstall, 'MYPATH added to Environment table.'); finally MsiCloseHandle(View); end; finally MsiCloseHandle(Db); end; end; end;[/CODE] Hope this help ! Adrien

Adrien · ‎Nov 04, 2013

Hi, I need to add a path without last path delimiter in environment strings. According to the log, the property I write in the Environment table is correctly formatted (without last path delimiter), but value written by WriteEnvironmentStrings has the path delimiter: WriteEnvironmentStrings: Name: MyEnvString, Value: C:\Test\, Action 536870913 ... Property(S): MyProperty = C:\Test The Environment table: [CODE]Environment Name Value Component_ NewEnvironment1 *=-MyEnvString [MyProperty] MyComponent[/CODE] So, after installation, it's impossible to use paths like %MyEnvString%\SubDirectory (user need to search for %MyEnvString%SubDirectory, that is not usual). Is there a way to do that ? Thanks for help, Adrien

Adrien · ‎Oct 10, 2013

Hi, and thanks for answer ! Indeed, it's a minor upgrade. And you were right, I can see a cached 1036.mst in C:\Windows\Installer\{my product code}. If I delete it before update, new shortcuts use the good updating strings. However, I haven't found any solution by playing with REINSTALLMODE property to solve my problem... Unless remove the cached mst, localized shortcuts aren't updated. The only solution I found is to use display resources for my shortcuts. Thereby, when resource dll is updated, shortcuts are correctly updated too. The downside to this is that, according to Installshield help, display resources are not supported by Windows XP and earlier : Windows Vista and later and Windows Server 2008 and later include support for the display resource. Earlier systems ignore it. But it clearly seems to be the cleanest solution for me (no longer need to manually delete old shortcuts). For Windows XP users, I will use display names without version number for my shortcuts... Thanks for help ! (I stay interested in any alternative, of course)

Adrien · ‎Sep 05, 2013

Hi all ! I have an issue when updating the display name of localized shortcuts... As an example: In a basic MSI project, I make an application in version 1.1.1 with 2 languages (in my case: 1033 and 1036... sorry for my poor english !). Default language is english (1033). I build 2 shortcuts: Shortcut A and Shortcut B. Shortcut A has the same name in english and french installation. Shortcut B is localized. So I have: "Shortcut A 1.1.1"/"Shortcut A 1.1.1", "Shortcut B GB 1.1.1"/"Shortcut B FR 1.1.1" (respectively in 1033/1036 languages). In version 1.1.2 of this application, I rename the 2 shortcuts in "Shortcut A 1.1.2"/"Shortcut A 1.1.2" and "Shortcut B GB 1.1.2"/'Shortcut B FR 1.1.2". I complete RemoveFile table to clear the "xxx 1.1.1" shortcuts. When I install the application 1.1.1 on a computer, shortcuts "xxx 1.1.1" are created (ok). Next, I update the application to 1.1.2. According to the log, shorcuts "xxx 1.1.1" are correctly deleted: RemoveFiles: File: Shortcut B FR 1.1.1.lnk, Directory: C:\Users\Public\Desktop\ RemoveFiles: File: Shortcut A 1.1.1.lnk, Directory: C:\Users\Public\Desktop\ But the new shortcuts are: CreateShortcuts: Raccourci : SHORTC~1.2|Shortcut A 1.1.2 CreateShortcuts: Raccourci : SHORTC~1.1|Shortcut B FR 1.1.1 There is absolutly no "Shortcut B FR 1.1.1" in the 1036.mst file of the 1.1.2 application, only "Shortcut B FR 1.1.2". So, where is the problem ? Is there a solution ? Thanks, and have a good day 🙂 edit: I have no problems with english installation. "Shortcut B GB 1.1.1" is correctly renamed to "Shortcut B GB 1.1.2".

Adrien · ‎Jan 22, 2013

Thanks ! To keep the actual ShowMsiLog custom action in none admin installation, I have cloned it and edited this new "ShowMsiLogAdmin" as described in the release notes. Then in SetupCompleteError, SetupCompleteSuccess and SetupInterrupted dialogs, I have changed the ShowMsiLog event of "OK" or "Finish" buttons to launch it only in none admin installation, and I have added the ShowMsiLogAdmin event : DoAction | ShowMsiLog | And ACTION<>"ADMIN" DoAction | ShowMsiLogAdmin | And ACTION="ADMIN" Now it works perfectly ! 🙂

Adrien · ‎Jan 16, 2013

Hi all, When I do administrative installation, "Show the Windows Installer log" checkbox on the SetupCompleteSuccess dialog does nothing, even if the log file is correctly created in %temp% folder. When I do standard installation (no /a parameter), "Show the Windows Installer log" correctly open the installation log if checked. Is this a known problem ? Is there a way to fix it ? I have done the test on a Windows 7 32 bits computer. Both logs (from administrative installation or standard installation) end with "ISSHOWMSILOG = 1" with a correct MsiLogFileLocation. Events of the "OK" button in SetupCompleteSuccess dialog are : EndDialog | Exit | 1 DoAction | ShowMsiLog | MsiLogFileLocation And (ISSHOWMSILOG="1") And NOT ISENABLEDWUSFINISHDIALOG DoAction | IS_LAUNCH_MY_PROGRAM_PLEASE | LAUNCHPROGRAM Thanks !

Online Status	Offline
Date Last Visited	‎Jul 07, 2020 06:02 AM

Re: Cache path for packages in suite projects

Cache path for packages in suite projects

Re: Best practices for MSI cache

Best practices for MSI cache

Re: MSI parameters to uninstall old package during major upgrades ?

MSI parameters to uninstall old package during major upgrades ?

Modal results in Suite Projects (secondary windows)

Re: Empty values in ini files

Empty values in ini files

Re: Last path demiliter in environment strings

Last path demiliter in environment strings

Re: Localized shortcuts update

Localized shortcuts update

Re: "Show the Windows Installer log" doesn't work after administrative installation

"Show the Windows Installer log" doesn't work after administrative installation