This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Suite installation suggestion
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 30, 2011
10:50 AM
Suite installation suggestion
I am currently experimenting with the new Suite installation type available in InstallShield 2012 Premier. Since packages are meant to be a replacement to InstallShield Prerequisites, I am trying to remove prerequisites from my main product installer and make them dependency packages of the suite. There does not appear to be a migration path to do this, though. It would be nice to be able to import an existing prerequisite and make it a suite package. Additionally it would be great to have some standard packages available (.NET Framework, Windows Installer, VS Runtimes, etc) like there are for prerequisites. I am very pleased with the flexibility that the detection and eligibility conditions allow, but manually re-creating suite packages based on existing prerequisites is rather tedious.
(19) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 30, 2011
02:47 PM
I've submitted the feature request work order #IOA-000065350 to take it into consideration.
Thank you for the great feedback!
Thank you for the great feedback!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 04, 2011
11:21 AM
I second this idea! The reason this would make sense (to me at least) is becuase I have the same prerequisites in 4 of the 5 different packages, thus the final install package I need to distribute is MUCH larger than it really should need to be.. (ie: .Net 4.0 x 4, Visual C ++ runtimes x4), etc..
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 11, 2011
11:10 AM
ditto
Another suggestion (maybe this is possible, but I did not find out how to do it): let the suite install from specified subfolders
Our installation medium looks like
But when I package them in a Suite installation, I get
It would be great if we could maintain our CD structure, as it is also an option for our customers to install only one of the subprojects - and they don't like to mess with GUIDs
And another issue about localization:
We'd like to display the installation UI from the packages (e.g. MainApp.msi). It would be OK for us to simply let the Suite start the setup.exe, but it should start with the language that already was chosen for the Suite. If there would be a Suite property similar to ProductLanguage, we could use this for the package's command line.
Another suggestion (maybe this is possible, but I did not find out how to do it): let the suite install from specified subfolders
Our installation medium looks like
|
+--MainApp
| +--MainApp.msi
| Setup.exe
+--AnotherApp
| +--AnotherApp.msi
| Setup.exe
\--Tools
\--ToolApp
+--ToolApp.msi
Setup.exe
But when I package them in a Suite installation, I get
SuiteSetup.exe
+--{MainAppGUID}
| +--MainApp.msi
| Setup.exe
+--{AnotherAppGUID}
| +--AnotherApp.msi
| Setup.exe
\--{ToolAppGUID}
+--ToolApp.msi
Setup.exe
It would be great if we could maintain our CD structure, as it is also an option for our customers to install only one of the subprojects - and they don't like to mess with GUIDs
And another issue about localization:
We'd like to display the installation UI from the packages (e.g. MainApp.msi). It would be OK for us to simply let the Suite start the setup.exe, but it should start with the language that already was chosen for the Suite. If there would be a Suite property similar to ProductLanguage, we could use this for the package's command line.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 13, 2011
03:48 PM
There is such a property (although there's a buglet where it doesn't get set in certain situations that we will resolve soon), called ISSelectedLanguage. You can use this on your package's command line.
I've also taken a feature request note for specifying the location of your package's files in an uncompressed build. I agree that the GUIDs are a little unsightly.
I've also taken a feature request note for specifying the location of your package's files in an uncompressed build. I agree that the GUIDs are a little unsightly.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 14, 2011
03:24 AM
Great, thank you
🙂
🙂
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 14, 2011
06:45 AM
Michael,
I have the same issue as 'the_boz' as far as folder structure and GUIDs.
Thank you very much for considering "specifying the location of your package's files in an uncompressed build". 🙂
I would like to display the source folder names rather than a GUID which means nothing to our users.
I have the same issue as 'the_boz' as far as folder structure and GUIDs.
Thank you very much for considering "specifying the location of your package's files in an uncompressed build". 🙂
I would like to display the source folder names rather than a GUID which means nothing to our users.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 17, 2011
10:26 AM
It looks like there's a workaround today for this. If you close the project, and open it in an XML (or text editor if you're careful), you can modify the //Parcels/*/Package/Folder/@Name attribute (look for under a element) to change it from a GUID to the name you want. I haven't tested this for download support, but it doesn't sound like that's your use case.
Test your use cases thoroughly, and keep a backup, of course. 😉
Test your use cases thoroughly, and keep a backup, of course. 😉
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 17, 2011
12:23 PM
Wow, it works as you described. Even with subfolders!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2011
11:04 AM
I tried to use the ISSelectedLanguage property you described for applying the matching .mst file to a multilanguage .msi package, but I failed to create the correct Command Line. How can I make the suite install the MSI package in the selected language? Currently the displayed actions in the status line are always English (the MSI's default language) and also is the UI in a maintenance installation of the product.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2011
06:14 PM
Hmm. The approach I would suggest is specifying a command line for your MSI package that includes TRANSFORMS="[ISPREREQDIR][ISSelectedLanguage].mst" (or /L[ISSelectedLanguage] for an exe). The .msi case assumes that you include the transforms next to your .msi in the root of the package.
To debug this, I would suggest a combination of the debuglog (see Troubleshooting Issues by Logging a Suite Installation) and MSI logs (for now either specify the always log option in the .msi project, or turn on the logging policy on your machine). Verify that the correct transform is being applied.
Unfortunately I'm uncertain whether the messages from the .msi are translated or reflect the underlying language of the OS. Let's rule out the possibility that the transform is not being specified first, though, and then tackle the other possibility.
To debug this, I would suggest a combination of the debuglog (see Troubleshooting Issues by Logging a Suite Installation) and MSI logs (for now either specify the always log option in the .msi project, or turn on the logging policy on your machine). Verify that the correct transform is being applied.
Unfortunately I'm uncertain whether the messages from the .msi are translated or reflect the underlying language of the OS. Let's rule out the possibility that the transform is not being specified first, though, and then tackle the other possibility.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2011
05:45 AM
Thank you very much for your useful information. It helped me a lot to understand and to hack 🙂 suite installation. It would be helpful if the capabilities of the Suite project type were supported by the UI and documentation as well.
Unfortunately your proposal regarding the ISSelectedLanguage property doesn't work as expected.
As you can see from the log, in the Final command line the ISSelectedLanguage resolves to empty, although otherwise in the log file it resolves correctly to 1031 (German). The ISPREREQDIR property always resolves correctly.
Another suggestion regarding the LicenseAgreement dialog: It would be useful if the license text files needn't have the same name for different languages. For example use License_EN.rtf, License_FR.rtf, License_DE.rtf from the same folder.
Unfortunately your proposal regarding the ISSelectedLanguage property doesn't work as expected.
...
10-24-2011[12:04:46]: Engine: starting parcel operations
10-24-2011[12:04:46]: Engine: property 'ISInstallStatus' value now 'IDS_SUITE_PREPARING_FOR_OPERATION'
10-24-2011[12:04:46]: UI DLL: Get: Property=ISInstallStatus Value=IDS_SUITE_PREPARING_FOR_OPERATION Return Code=0
10-24-2011[12:04:46]: Transaction: parcels installing: yes, need elevation: no, any 64-bit: no
10-24-2011[12:04:46]: Engine: request for proxy handler, 0, 0
10-24-2011[12:04:46]: Running with current process transaction, starting transaction (if supported)
10-24-2011[12:04:46]: Running transaction parcels
10-24-2011[12:04:46]: Running parcel operation for parcel {0878804F-A51E-4BCC-93A4-08A287AB34A9}
10-24-2011[12:04:46]: Running MSI parcel operation
10-24-2011[12:04:46]: MSI parcel detect: product code: '{A70D2128-C240-481F-B1B0-28F80D8438BF}', package code: '{8C694353-2CAB-4D1D-BCD0-3842C2464335}', patch code: ''
10-24-2011[12:04:46]: MSI parcel detect: evaluate status: 0, is installed: false
10-24-2011[12:04:47]: Using parcel operation target
10-24-2011[12:04:47]: MSI parcel operation, mode: 0, operation mode: 1
10-24-2011[12:04:47]: Engine: property 'ISInstallStatus' value now 'Paket wird installiert'
10-24-2011[12:04:47]: UI DLL: Get: Property=ISInstallStatus Value=Paket wird installiert Return Code=0
10-24-2011[12:04:47]: MSI parcel command line: TRANSFORMS="[ISPREREQDIR][ISSelectedLanguage].mst"
10-24-2011[12:04:47]: Not running as upgrade
10-24-2011[12:04:47]: Feature command line: ADDLOCAL=Samples,Product
10-24-2011[12:04:47]: Final command line: TRANSFORMS="H:\DiskImages\Disk1\MyProduct.mst" ISPREREQDIR="H:\DiskImages\Disk1\MyProduct" SETUPEXEDIR="H:\DiskImages\Disk1" SETUPEXENAME="Setup.exe" ADDLOCAL=Samples,Product
10-24-2011[12:04:47]: MSI parcel launch result: 80070658
10-24-2011[12:04:47]: Engine: property 'ISInstallProgress' value now '0'
10-24-2011[12:04:47]: Engine: property 'ISParcelProgress' value now '0'
10-24-2011[12:04:47]: Engine: property 'ISInstallStatus' value now 'Vorgang für Paket abgeschlossen'
10-24-2011[12:04:47]: UI DLL: Get: Property=ISInstallStatus Value=Vorgang für Paket abgeschlossen Return Code=0
10-24-2011[12:04:47]: Parcel operation return status: 80070658
10-24-2011[12:04:47]: MSI parcel detect: product code: '{A70D2128-C240-481F-B1B0-28F80D8438BF}', package code: '{8C694353-2CAB-4D1D-BCD0-3842C2464335}', patch code: ''
10-24-2011[12:04:47]: MSI parcel detect: evaluate status: 0, is installed: false
10-24-2011[12:04:47]: Re-running parcel detection for parcel {0878804F-A51E-4BCC-93A4-08A287AB34A9}, install state: 0
10-24-2011[12:04:47]: Transaction: parcel returned error status 80070658
10-24-2011[12:04:47]: Transaction: finished running parcels, will roll back transaction
10-24-2011[12:04:47]: End transaction result: 1
10-24-2011[12:04:47]: Engine: error 80070658 while running parcel operations
10-24-2011[12:04:47]: Engine: parcel operations completed, sending completed event to UI
10-24-2011[12:04:47]: Engine: property 'ISInstallStatus' value now 'IDS_SUITE_INTERRUPTED'
10-24-2011[12:04:47]: UI DLL: Get: Property=ISInstallStatus Value=IDS_SUITE_INTERRUPTED Return Code=0
10-24-2011[12:04:47]: UI DLL: Get: Property=SETUPSUPPORTDIR Value=C:\DOKUME~1\.......\ Return Code=0
10-24-2011[12:04:47]: UI DLL: Get: Property=ISSelectedLanguage Value=1031 Return Code=0
10-24-2011[12:04:47]: UI DLL: Get: Property=SETUPSUPPORTDIR Value=C:\DOKUME~1\.......\ Return Code=0
10-24-2011[12:04:47]: UI DLL: Get: Property=ISSelectedLanguage Value=1031 Return Code=0
10-24-2011[12:04:47]: UI DLL: Get: Property=ISInstallStatus Value=IDS_SUITE_INTERRUPTED Return Code=0
10-24-2011[12:04:47]: Engine: property 'ISCurrentPage' value now 'InstallationComplete'
...
As you can see from the log, in the Final command line the ISSelectedLanguage resolves to empty, although otherwise in the log file it resolves correctly to 1031 (German). The ISPREREQDIR property always resolves correctly.
Another suggestion regarding the LicenseAgreement dialog: It would be useful if the license text files needn't have the same name for different languages. For example use License_EN.rtf, License_FR.rtf, License_DE.rtf from the same folder.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2011
11:07 AM
Hmm, it looks like I may also be missing a slash in what I recommended. I think population of the ISSelectedLanguage property depended on some UI interaction in RTM; that should be fixed for SP1.
And I hear you about using alternate names instead of alternate folders for your EULAs. I'll put this on our list of things to make better, but I'm not sure the right way to approach this one.
Hmm, if you just have a couple languages, you might try adding a few overlapping Rich Text Box controls and condition set their Visibility to {Binding ISSelectedLanguage==1033}, etc., with alternate Resource settings on each.
And I hear you about using alternate names instead of alternate folders for your EULAs. I'll put this on our list of things to make better, but I'm not sure the right way to approach this one.
Hmm, if you just have a couple languages, you might try adding a few overlapping Rich Text Box controls and condition set their Visibility to {Binding ISSelectedLanguage==1033}, etc., with alternate Resource settings on each.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 25, 2011
03:39 AM
Thank you very much for your support
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 24, 2012
10:27 AM
I have the same problem but can't seem to have .mst file in the folder described in ISPREREQDIR. Only msi.
So i used TRANSFORMS="[ISPREREQDIR][ISSelectedLanguage].mst" as you suggested but no luck. If I put the path to my mst file instead of using ISPREREQDIR, I manage to get the good results. Please help.:confused:
edit: Solved by changing location in general tab of the msi package file, from "extract from setup.exe" to "copy from source media".
So i used TRANSFORMS="[ISPREREQDIR][ISSelectedLanguage].mst" as you suggested but no luck. If I put the path to my mst file instead of using ISPREREQDIR, I manage to get the good results. Please help.:confused:
edit: Solved by changing location in general tab of the msi package file, from "extract from setup.exe" to "copy from source media".
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 24, 2012
04:25 PM
that way i got every .msi package in its own folder, which I like. But, there is another problem The package folder names are GUID-like (meaning like {123412342xxx}). I do not see any option to change that folder name. Instead, iI can open the suite project file and edit the folder tag in order to change package folder names. Is there a better way of doing this?
(sorry for double post)
(sorry for double post)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 25, 2012
03:32 PM
There is no way to change the folder name in the IDE today, sorry.
As far as the mst goes, have you checked the output of /debuglog to see what path it calculates when using the TRANSFORMS="[ISPREREQDIR][ISSelectedLanguage].mst" version? How close or far is it from what you hardcode?
As far as the mst goes, have you checked the output of /debuglog to see what path it calculates when using the TRANSFORMS="[ISPREREQDIR][ISSelectedLanguage].mst" version? How close or far is it from what you hardcode?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2012
09:27 AM
MichaelU wrote:
There is no way to change the folder name in the IDE today, sorry.
As far as the mst goes, have you checked the output of /debuglog to see what path it calculates when using the TRANSFORMS="[ISPREREQDIR][ISSelectedLanguage].mst" version? How close or far is it from what you hardcode?
I actually had to include mst files in the package files of the suite. that way it worked.
I also had a problem that when I'm installng a suite and i don't select the language from the menu, but only click next button, ISSelectedLanguage property is empty and TRANSFORMS get the value i.e. "c:\path\.mst" (no mst name), so I actually needed to add ISSeleced language=1033 for the suite to run in default english.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 01, 2012
10:22 AM
Do you have the SP installed? I thought the problem with ISSelectedLanguages not being populated before being changed was fixed in the SP.
But adding the .mst to the package's file was definitely the right approach; that's what gets it into ISPREREQDIR at installation time.
But adding the .mst to the package's file was definitely the right approach; that's what gets it into ISPREREQDIR at installation time.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 02, 2012
03:50 AM
MichaelU wrote:
Do you have the SP installed? I thought the problem with ISSelectedLanguages not being populated before being changed was fixed in the SP.
But adding the .mst to the package's file was definitely the right approach; that's what gets it into ISPREREQDIR at installation time.
I don't have sp installed, and I am using stand alone build. Thanks for your support, and I'd like you to see if this problem can be fixed
http://community.flexerasoftware.com/showthread.php?t=200375
since it's something tied to the multilanguage support and would be nice if it was fixed.