I am using InstallShield 2019 R3
I have specified some arguments in the "MSI Command-Line Arguments" field under Releases -> Setup.exe.
When I build directly from InstallShield 2019 Application, these Arguments are packaged into the Setup.exe file.
When I build using IsCmdBld the arguments that I have specified are ignored and are not added to the setup.ini file under [StartUp]CmdLine=
Is there a specific switch I need to use to have these included when using IsCmdBld or maybe I am doing something wrong?
I have tried different package types (Network Install, Web etc) and they all seem to have the same issue. I have also posted on the Flexera Community, but so far not had any responses!
Any help would be greatly appreciated :)
Related
0x80070652 - when installing VS 2012 C++ redistributables.
Hi All,
I have a weird issue for the last few days now, i've been looking for a solution in the forums, google etc.
So far, couldn't find a similar problem:
Scenario:
I have an "Basic MSI" project that deploy our company product.
everything worked OK till i needed to add installation of VS 2012 C++ redistributables.
i'm using the installscript to initiate a command line for installing it quietly - 'vcredist_x64.exe /q'.
if the custom action is being added to the execute sequance, the following error is coming from the "VS 2012 C++ redistributables. -
ERROR 0X80070652: ERROR_INSTALL_ALREADY_RUNNING.This error is due to Another installation is already in progress. Complete that installation before proceeding with this install.
if running it manually, regardless to the IS installation, everything is working perfectly.
Also, when the custom action is on the UI sequance - works great. - i cannot leave it on the UI sequance, since our product is being deployed quietly along with our product client.
I've been trying to change into a different project type - "installscript MSI"... Same error.
Please advise, thanks for any inputs.
Short Answer: You can't run this executable from inside your MSI for technical reasons, you should run them in sequence instead. First the executable, then your MSI (batch file or manually). Or you should make an executable that runs them in sequence (WiX Bundle for example).
VCRedist: The VS 2012 C++ redistributable vcredist_x64.exe is a WiX Bundle with a couple of MSI files inside. You are not allowed to run embedded / nested MSI files concurrently with the main MSI installation. Simple explanation here. Inline explanation: This is because MSI files install as a transaction that is supposed to be possible to roll back. Hence the file installation sequence locks the system to prevent other MSI files installing when one is already in progress.
Extract: You can extract a WiX bundle using the WiX toolkit's dark.exe: dark.exe /x D:\VCRedist vcredist_x64.exe. WiX toolkit must be installed and dark.exe must be in the path or you must specify its full path.
Setup.exe: The solution is to run the MSI files in sequence inside a setup.exe bundle created with WiX, Installshield (see link for sample screenshot - more on suite projects here), Advanced Installer or a similar setup creation tool. Another approach is to simply deliver the runtime next to your installer and install them in sequence with a batch file or even by instructing the user to do so.
Merge Modules: Most VCRedist versions have merge modules that you can use to install the runtime (as opposed to setup executables). WiX sample. These are merged into your own MSI at build time and hence feature no nested MSI processes. There are some issues with merge modules and recent VCRedist versions.
Links:
The latest supported Visual C++ downloads
Detect VC runtime presence
Similar answer
I was using InstallShield 2011 (licensed version) to build .ism and .uip InstallShield projects and create .exe and .bin files from them. Since I was using command-in-line arguments (IsCmdBld.exe, InstallShieldUniversalCommandLineBuild.exe) with the above .ism and .uip projects to build, it's pretty easy for us to and create setup.exe and setup.bin from them.
Our sample syntax:
exec executable="${installShield.home}/IsCmdBld.exe" dir="."
arg line=' -p "../ISScript/setup.ism" -r "${release}" '
exec executable="${installShield.universal.home}/InstallShieldUniversalCommandLineBuild.exe" dir="."
arg line='"../universal/setup.uip" -build ${release}'
The issue was raised when we were thinking of upgradation of InstallShield to the latest version, we couldn't find the build tool (InstallShieldUniversalCommandLineBuild.exe) in the latest package. So the installers (.bin) creating for UNIX based platforms are stopped.
FYI: While we were using InstallShield 11 (licensed version) to create the universal installer (.uip) using "InstallShieldUniversalCommandLineBuild.exe" as an executable, we had a package named "Universal" in our InstallShield 11, which contained the above command line too.
We would be happy if you could help us with this.
It's not completely clear what your question is, but I think it's along the lines of “How do I build a .uip project with a current offering from Flexera?” And, while I have some clarifications to offer (and I will), the bottom line is that the product that handled .uip projects was discontinued long ago, so there's likely to be some significant migration work.
In the InstallShield 11 era (2005 or so), the Windows and non-Windows branches of InstallShield were packaged together as a product called InstallShield Universal. Since then, two relevant things changed. The combined packaging was discontinued, so if you need to support both Windows and non-Windows, Flexera's products are once again separate offerings. Also, after ZeroG's InstallAnywhere joined the family, the long term result was that InstallShield Multiplatform was discontinued, and InstallAnywhere survived as the non-Windows offering.
So the important question is what sort of upgrade path there is from your .uip into InstallAnywhere. This is outside my knowledge (I just worked on the Windows side), but there is a mention of Upgrading from InstallShield MultiPlatform in the InstallAnywhere documentation. Thus I wouldn't rule it out. And once you sort that out, you'll have to adjust your build script to use either build.exe or Ant, by the looks of it.
I am working with a setup project of Visual Studio 2015. I want to distribute the 2015 C++ library, vc_redist.x86.exe. But I don't want user to be aware of this pre-requisite, so the idea is that while he is running the .msi, the C++ library will be auto-installed.
I have been reading about the merge modules, but this cannot fix my problem because the setup.exe should be run. Please, could anybody tell me how to deal with this?
Many thanks!
You'll need to change (or create your own custom one) the standard bootstrapper that has documentation starting here:
https://msdn.microsoft.com/en-us/library/ms165429.aspx
The bootstrapper packages contain the detection and install logic for the redistributables. For example, the \Bootstrapper\Packages folder has VC redist folders, each with a product.xml and a package.xml about installing them as prerequisites. They have standard command lines such as:
Command PackageFile="vcredist_x64.exe" Arguments=' /q:a
and you can substitute that command with something like those listed here:
http://asawicki.info/news_1597_installing_visual_c_redistributable_package_from_command_line.html
that show the quiet options (as do standard Microsoft docs somewhere).
I have a big Installshield 2010 Basic MSI project that creates an executable installer.
I would like to make this Installer run silently, but the supposed built-in /S and /SMS options don't appear to work. I figure I have to explicitly handle it within the .ISM itself, but don't know how, and so far my Googling has only returned help with things like SilentReadData() and SilentWriteData for InstallShield Scripts. (See http://kb.flexerasoftware.com/doc/Helpnet/installshield15langref/LangrefSilentReadData.htm) I don't think this is the right way to go, as I have no scripting currently in my .ISM file.
What other information do you need to know to help me?
Can someone point me in the right direction?
Running on Windows 7, creating an installer for a 32-bit executable targeting X86.
If you're using an InstallScript UI (common to the InstallScript and InstallScript MSI project types), any custom dialogs need to have SilentReadData and SilentWriteData calls (conditioned on MODE) like you found. However if you have no script at all, you are probably using a Basic MSI project instead. For these, you need a different command-line parameter to make it silent, such as /v"/qb" or /v"/qn"; you may also need to provide some property definitions for any non-default settings, in the format /v"/qb PROPERTY=\"Value\"".
Being forced to use the garbage version of LE in VS 2012, I cannot get things to build because it is telling me that my install folder path is too long. It literally looks like it is creating the same path, verbatim, inside of another folder. First this fails on the DVD so can I disable that? Second, this appears to be controlled by the variable ISProductFolder but I cannot find how to modify that location.
Can somebody please help?
Well, it is not surprise that each setup tool has its problems. Please note that there are no tools which can accurately detect your application dependencies. The best a tool can do is make suggestions. This is why most setup developers determine the dependencies themselves and manually include them in the installer.
If you're not happy with InstallShield, you can try a different setup tool: http://en.wikipedia.org/wiki/List_of_installation_software
The free version of Advanced Installer includes a Visual Studio setup project which may help.