I am building an MSI to install our company's product with InstallShield 2010, and it needs to apply several Windows hotfixes in the installation that the product needs to run.
I was wondering what's the way to accomplish this using InstallShield? Using prerequisites?
It took me a while to understand how to even define a new prerequisite, and they seem to be pretty limited in the conditions they provide to check if my hotfix is already installed, and what's the exact Windows version I'm running on. Moreover I would need to define a prerequisite for each version of Windows and each architecture which creates a massive bloat of prerequisites.
Until now we used python scripts that the MSI would run just before termination that would apply these hotfixes, but as of Windows Server 2008 this is no longer possible, and the installation of the hotfixes fail.
I remember I saw sometime an installation of some enterprise product (SQL Server or Oracle) that applied Windows hotfixes in its installation process, and it seemed a pretty standard procedure. I was wondering if there is a convention to how it can be done?
You'll need to do this with prerequisites, so that the Installshield bootstrapper EXE installs the hotfixes before launching your MSI. (multiple MSI's can't run simultaneously, and chances are these hotfixes contain an MSI)
Related
2 files required for the MS DHTML control to work properly were removed from windows vista (and win7, 8 presumably) for security reasons.
These are the DHTMLED.ocx and TRIEdit.dll.
Microsoft now supply a downloadable msi file, dhtmled.msi, which will install and register the 2 components into the following directory:
%windir%\Program Files\Common Files\Microsoft Shared\dhtmled\
I would like to build this into an inno script.
Should I run the installer on my machine first to get hold of the ocx and dll files and have separate lines for each in the inno script or should I incorporate the msi file into the script?
Also what flags should I use to prevent installation on win xp or earlier and when the files are already present?
Thanks
See Replacing the DHTML Editing Control in Windows Vista and Beyond
For new applications, you can ship the installer as part of your product (with appropriate licensing) and chain to it from your own installer. The installer can be run silently and without adding an item to the installed-programs list in Windows. (For details, see the documentation for MsiExec.exe.)
However, we recommend that the installer allow the DHTML Editing Control to be added to the installed-programs list. In addition, when your application is uninstalled, do not uninstall the control; instead, allow customers to uninstall it separately if they want.
Note that this method of installation does not provide logo-compliant installation.
The method that is compliant would be to list this as a prerequisite that the user manually installs before running your installer.
I haven't seen anything the permits redistribution of the naked libraries under any circumstances.
I'm using Advanced Installer in my product. as part of the installation, the installer installs c++ redistributables that my product needs in order to run. my question is how to prevent the user from removing the c++ redistributable installation in add/remove programs? is there an option to use reference counting on 3rd party products that the installer installs?
Have you considered using merge modules to install your redistributables? Instead of separate standalone installers. This is supported by Advanced Installer too.
This should prevent them from appearing in Control Panel, but they will also be uninstalled together with your application.
If you want to prevent the user from removing the redistributable installation from Add/Remove programs, please see the MSDN documentation: Configuring Add/Remove Programs with Windows Installer. You could use the ARPSYSTEMCOMPONENT property to prevent the redistributable from being displayed in the Add or Remove Programs list of Control Panel. This should hide the redistributable installation, but you can still use the Windows Installer to install, uninstall, repair, and reinstall the application. If the user uninstalls your application, it should be designed to also uninstall the redistributable. The recommended alternative to using concurrent installations is to instead use a setup application and external UI handler to install several Windows Installer packages sequentially.
Note however that Microsoft recommends that no one use concurrent installations to install or update a shipping product. A concurrent installation action installs another Windows Installer package during a currently running installation.
I am using Visual Studio 2010 setup project
I don't think you are allowed to redistribute PowerShell. And at any rate, it is built in to Windows 7 and Server 2008 R2. All the other platforms have separate installers as well. I think it would be best to just notify your customers that they need PowerShell 2.0.
I had a similar problem in the StudioShell installer - wanted to make sure PoSh 2.0 is installed. I did a cursory check for the executable with a minimum version number, and added a launch condition that notified the user of the missing prerequisite and offered to open a web page to the PowerShell download. Seemed like the most legally helpful approach.
There is a way, albiet requiring you to build some MSI thing manually that will get it from MS and install it for you. I know the exchange install used that technique. You can also get a license/permission from MS to redistribute the official installers.
Is it possible to create MSI package, which will run without Windows installer installed in system, but first will install Windows installer itself, and then continue installing other components?
The goal is to create prerequisite package for our software, which must install some components, including some operation system service packs. We also prefer using MSI package. But it's obviously to us that our software will be installed on clean operation system. Though there will not be needed Windows installer present. Is it possible to create such prerequisite package using MSI?
No, there is no way to install an .MSI package without Windows Installer already being present in the OS.
However, Windows Installer has been a native part of Windows since Windows 2000. Are you really developing installers for Windows 95/98/NT4? That would be the only case where there is no Windows Installer support and you'd need to install a redistributable MSI package first.
Unless you meant to say that you require a higher version of Windows Installer than is native to one of the older OSes? (e.g. MSI 3.1 for WinXP) In that case, you'll need to bundle the .MSI redistributable for the MSI package you desire and run that first. Sometimes a reboot is required, other times not. YMMV.
One way, you can write an application in cpp or c or any language that does not require any additional frameworks or SDKs, to check for the installer and install it programatically.
It sounds like you need a bootstrapped with two or more msi files in it. Take look at the WiX documentation. WiX has build-in bootstrapped
Hope this helps
s
I have a windows installer (MSI) project. I want to ensure that when i build it , it will be compatible with msiexec version 4.5.
Normally, compatibility is a problem with a lower verions. Windows Installer 4.5 is the latest version of windows installer and I would expect it to be backward compatible. So, most likely things that you are using will be supported.
What you should worry about is compatibility with older versions of Windows Installer. Most IDEs for creating installers would let you know if you are using something that is available only after some version of Windows Installer onwards.
If your IDE does not provide this feature then you should be aware of what all you are using in your MSI and make sure thats its available in the Windows Installer version you intend to you target with your installer.
That depends on the tool you use to build the MSI, you should be able to specify the required installer version there.
For example, WIX, which I frequently use has a "InstallerVersion" attribute at its "Package" XML Element. There I can specify which Windows Installer Version is required.
(Currently I do not require Installer 4.5 as it isn't deployed everywhere yet and I don't want to require customers to install the new installer on XP.)
Update:
Re-reading your question I get the impression that you use a Visual Studio Installer project. I believe you can't configure the Windows Installer Version there, but it defaults to Windows Installer 3.whatever (I'm not sure about the specific minor version). Setups created with that are compatible with Windows XP in any way.
I don't believe you WANT to require a newer version of Windows Installer when you use a Visual Studio setup project, as the setup project is very limited in what it can do. So to require a newer version of the installer you probably have a specific feature in mind (for example elevation on Vista). To use that feature you'd need a better tool to build installers anyways (like WIX, or Installshield or Wise or ...)