Software Deployment Question

Pass Setup.exe Language Selection to a Prerequisite ...

07/14/2016 1247 views

Hi all,

I'm trying to run a widget with a dialog box as a prerequisite.  I'm wondering if I can pass the language selection for the Setup.exe to the prereq.  If so, what is the property that can be passed on the command line in the Prereq properties.

2 Comments   [ + ] Show comments


  • I'm using InstallShield 2015 by the way.
  • HI @Superfreak3 , you found the solution for this , I amalso facing the same problem....Please suggest

All Answers

In my experience, that prompt from the set-up stub only controls the language of the installation, not the product itself. Product language selection occurs elsewhere.
Answered 07/18/2016 by: VBScab
Red Belt

  • Yes, I realize that. I'm dealing with the installation only, not the actual app. I just need to know how to pass the Setup.exe selected language to a prerequisite, not govern the actual apps runtime language.
This is assuming its a MSI - if not then you're buggered and will need to think of plan b.

Is this something you can select/choose and it passes it on via the GUI? If so then enable full MSI debug logging with the registry below, install the software and look in your %temp% for the logs. Have a rummage and see if you can find the property its passing.

Save and import this reg to enable full msi debug mode.

Answered 07/15/2016 by: rileyz
Red Belt

  • No, its not the .msi that I am looking into. This is the Setup.exe where a language dialog is displayed for selection Before the .msi is unpacked. I'm looking into how I can send the selected setup.exe language to my prerequisite.
    • That setup.exe language is somehow passed to the .msi so I'm hoping I can pass it to a prerequisite.
      • Yeah, what I said will work.

        Just pump in the reg keys and run your setup as normal, check the logs in your %temp%. You will see one log that is bigger than the others, at the top of the log you will see what params/PROPERTY where passed to the MSI.

        If its not the log you are looking for, have a hunt around in the other ones, if its a MSI (the one with the lang selection) and it will be in the %temp% logs.

        Like my old Infrastructure Team Lead said to me a long time ago - LOGS LOGS LOGS!
  • So you're saying log the Setup.exe? Or are you saying check the .msi log when the entire install is completed. If the later is the case I'm almost certain ProductLanguage would be passed in as that is what governs the UI language in the .msi I believe.

    I tried putting ProductLanguage and [ProductLanguage] as parameter in Prerequisite properties, but nether worked. The first thing I tried with these is displaying a message from my .exe that contained all the command line arguments. The only thing I get is arg(0) - the path to the running prerequisite .exe.
    • Ok, im really confused, can you explain how youre installing this please. Like the setup.exe, is the msi unpacked, what is this pre-req - where is it in the install process etc.

      I guess either your setup exe is trigger the pre-req, if this is the case then you will be hard pressed to find the arg it is passed. If its triggered by the MSI, then it will be possible.
      • When I compile the installation package it is wrapped in a setup.exe. In the InstallShield template the prerequisites are set to run before feature selection - before the .msi process kicks off. The prerequisites are things like the .net framework, vc++ runtimes, etc. In this particular instance I wrote my own widget that checks a service and stops it if running. I could just do it silently and all works fine, but we may have to give the user a choice, which will require localization. Hence I need the language selected with setup.exe passed to my widget.

        In short, take the .msi out of it as all of this occurs before the .msi is unpacked and executed.

        I do like the logging idea as it may give a clue of how setup.exe passes its selected language to the .msi, but as mentioned, I believe this would be ProductLanguage.
      • Ahh Im with you now. And its your own Installshield project, I didn't realise. You should of explained this better in the question.

        Hummm, Im not sure if I can help you as I never use the setup wrapper. i know the wrapper uses Installshield script (yuck) and he can do a lot of a pre loading, such as in your case.

        I'm thinking you should be able to do this with the setup.exe with Installshield scripting to launch the prereq with arg - your widget will need to handle this. As mentioned I dont use setup exe.

        Or you could do it from the MSI, if that is possible and if it works with your work/install flow? Either launch your widget from the MSI or why dont you get the msi to stop the service using a CA (unless the widget is doing more than that).

        Another thing, with your widget, why dont you just detect the OS locale and use that? instead of asking, query the OS.

        Anyway, since this is your IS project, you should defo be able to do this.
      • The issue with handling in the .msi is that as part of the prerequisites is a third party app. The service widget I've been describing is associated with that app. So, if the third party app needs to be upgraded, I have to deal with the service as their installation doesn't do it. This is all done before our .msi is extracted and fired up.

        As far as detecting the locale of the OS, the app language selected may not always match the locale of the OS. For example, we have folks that install fr-CA on English OSs.
      • Humm.

        I give up! lol. I don't use the setup.exe at all, I think you'll need to do a lot of reading on Iinstallshield. I'm sure there will be a way to pass a param/arg to your widget. I just don't know my self.
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