I have two installshield projects, I want to ask is it even possible to wrap an existing ism project within a wrapper ism project?!
The desired functionality is:
When i use custom installation and select to install the nested project it will behave as like i used it's native installer.
I'm using installshield 2011 Professional edition.
Thanks for helping.
I encountered this SAME problem. I wanted an installshield project to run another installshield project (which was an updater) to bring the software up to date before installing the first installer.
I solved this by creating a batch file.
1) The user launches the install msi.
2) The installer prerequisites detects that "previous version must be installed" by checking the registry and runs the batch file
3) The batch file kills the current process of installer and runs the second installer
4) Once the second installer is finished, the batch file re-runs the first installer (by using the batch command START /WAIT, which waits for a process to finish)
5) Now that the second installer was installed, the prerequisites doesn't trigger, and you resume with the installation.
You can, with caveats. If both of your projects are Basic MSI or InstallScript MSI, you will encounter the limitation that Windows Installer will only allow one MSI at a time. The end result of that is you can either run both safely through actions in the UI sequence (and fail if they are run silently), you might be able to use MSI Chaining (which I don't personally recommend), or turn one of the MSI packages into a prerequisite, or you have to find another way.
One option could be to add a third project, a pure InstallScript project, as a wrapper. If you go down this route, you have to consider what user experience you want for installation, maintenance, and uninstallation, including deciding what shows up in Programs and Features. Note that in later versions of InstallShield the Suite or Suite/Advanced UI project type is designed for this, but only in the Premier edition. (The Advanced UI project type in the Professional edition only allows for one main package, and you have two already.)
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 have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
I have created an MSI installscript project in Installshield. I went to Project Assistant>Application Files, then added the application files(package) and built Setup.exe to install.
After installed these files, I went back to Project Assistant and added some application files, then i changed the product version for updating. Finally, i built the Setup.exe again. When i run the Setup.exe, the automatic update (Upgrade Window Installer Setup) asked me to update a new version. After finishing, I checked Program Files(x86) and the updating didn't do anything, the old package was still here.
How can i update my new package? Is there any way to disable the Upgrade Window Installer Setup?
Thanks for the help.
In my humble opinion, most likely, you added new files to existing Component with keypath, which didn't change. Also you should check "Add\Remove Programs" snap-in in Control Panel to see if upgrade was applied - there should change version of your product.
So, I recommend you check Components, and re-allocate files to new Components if I had right. Also please read more about Components and Files. Could start from here.
Two words about InstallScript MSI project. From InstallShield documentation: Because this project type uses two different engines, it is more complex than pure InstallScript or Basic MSI installation projects. It is recommended only for advanced users.
So, if possible, use Basic MSI project - it's a bit simpler than InstallScript MSI for begginers.
I have an InstallScript setup created with IS 2011, which includes prerequisites: The prerequisites dialog immediately appears after executing setup.exe even before the welcome dialog.
Is there a way to change this behavior so that the prerequisites are installed at a later step during the setup e.g. when the real setup procedure is started (i.e. after the welcome dialog, license agreement, ...).
Also I want to avoid the prerequisites installation when my application is already installed and I execute setup.exe and choose the uninstall option.
InstallShield offers a scheduling for prerequisites that is kicked off after the Install button. This approach is called "Feature Prerequisites" in the InstallShield help. Do be aware that since the .msi is already running, it is a more complicated time, so certain prerequisites should not be scheduled there (and others may fail to serve their purpose if installed after the wizard panels).
In InstallShield 2012 and later, the suite project type supports installing multiple packages after a single wizard. In that model, prerequisites are just another package, and your use case is more directly supported.