cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rboutilier
Level 4

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.
Labels (1)
0 Kudos
(19) Replies
hidenori
Level 17

I've submitted the feature request work order #IOA-000065350 to take it into consideration.

Thank you for the great feedback!
0 Kudos
Binary_Poet
Level 3

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..
0 Kudos
the_boz
Level 4

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
|
+--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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
the_boz
Level 4

Great, thank you

🙂
0 Kudos
rguggisberg
Level 13

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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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. 😉
0 Kudos
the_boz
Level 4

Wow, it works as you described. Even with subfolders!
0 Kudos
the_boz
Level 4

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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
the_boz
Level 4

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.

...
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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
the_boz
Level 4

Thank you very much for your support
0 Kudos
denguri
Level 3

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".
0 Kudos
denguri
Level 3

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)
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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?
0 Kudos
denguri
Level 3

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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
denguri
Level 3

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.
0 Kudos