I have an old installer that is made with InstallShield 2015, its non-MSI based (I tried opening it with 7zip and could not --> non-MSI based, am I right?).
In general, I need to stop using InstallShield and migrate to Wix.
Is it possible some how to convert InstallShield it to Wix?
Using Wix, I need to detect if a previous version (the InstallShield version) is currently installed and automatically uninstall it and then continue with the normal Wix process. Is such a thing possible?
Thank You :-)
I'll add a quick answer for reference, though the problem appears solved already.
If the old Installshield setup is an MSI, you can use dark.exe from the WiX toolkit to "disassemble" an MSI into WiX source code (dark.exe can also decompile WiX setup.exe bundles - there is a somewhat messy description of this here: How can I compare the content of two (or more) MSI files?).
After some cleanup you can compile the WiX source to a new WiX-built MSI. A bit of knowledge and experience is needed for the cleanup to be successful (eliminating GUI sections, add a WiX GUI, realign source paths, clean up binary stream tables, etc... - not trivial, but not rocket science :-).
If the old setup was a legacy installer (not MSI), you can convert it to MSI by using a repackager tool to capture changes done to the system during installation and convert them to an MSI. A lot of knowledge is required to clean up such a capture. If you know the product it is often better to code a new setup "by hand". Or if you are in a large corporation chances are you will have a "repackaging team" available somewhere who will have the expertise to do this job for you.
Yes, old setups can be uninstalled as part of your new MSI.
As you discovered if the old setup was an MSI you can simply use a major upgrade to remove it during the new WiX install.
If the old version was a legacy setup things can get considerably more involved often requiring you to "record" a dialog response file to feed to the uninstaller function of the old setup.exe file. Not at all trivial, and quite error prone. Incidentally one of the major benefits of MSI is the completely suppressible GUI.
For reference, here is an old answer with information on dealing with the infamous setup.exe files that we frequently have to uninstall and upgrade:
How can I use powershell to run through an installer? The setup.exe can be many different things: Installshield Setup, Advanced Installer Setup, Inno Setup, Self-Extracting Zip-Archive, a proprietary setup format, the list goes on...
Related
When installing my software I need to take care another msi package is uninstalled before. Is this possible? Can burn do this for me?
MSI / Major Upgrade: You can add entries to the Upgrade table in one or all of the MSI files you install. Then the older / other MSI will be uninstalled before (or after) your MSI is installed. This is MSI's built in "major upgrade" feature intended to deliver upgrades for your own products, but you can uninstall any product you want that is MSI-based - even a competitive product - only if you are nuts, and do call legal first :-). Maybe see this description (related problem at least): Adding entries to MSI UpgradeTable to remove related products.
Burn: Burn can run EXE files that can initiate uninstall of pre-existing MSI files, but I would never choose this approach when you can use the above built-in MSI approach instead. I am not sure if you can call msiexec.exe directly via the ExePackage element of Burn, but you trigger the uninstall from within a custom made EXE file in a myriad of ways: Uninstalling an MSI file from the command line without using msiexec. It depends what your EXE is written in. If it is managed code, maybe use the DTF method (option 6 in the linked answer). If it is C++, maybe use the MSI API Win32 functions. See option 14 in the linked answer. I guess you can also chose to shell out to msiexec.exe (option 3). My advice: always go native code for deployment. Your setup must work on any machine, in any language, in any state and in any OS edition. There are many further variables. Minimal dependencies is the only cure.
I am having an MSI file which copies a set of dll from it source to destination folder. While running the MSI the dll are copied to the destination folder also the MSI is installed in the system. I can see that in ADD or REMOVE programs.
Whenever there is a change in dll, i copying the new dll and building the MSI again. When i tries to run MSI in the same system i am getting error "Another version is already. Uninstall that version and proceed" something like that.
What i am doing until now is uninstalling the old one (MSI) and installing the new one.
But i want the MSI to update the older dll with the latest dll from the MSI instead of uninstalling and installing again.
Thanks in advance.
You can't just rerun the MSI to do an update. There's some background here, even if you are not using Visual Studio setups, and it's still relevant after all this time:
https://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
To replace a single file, build a patch, an msp file. To upgrade the entire setup, including that Dll then use the WiX majorupgrade element, and that may be a lot easier than building a patch, especially if your setup is small and doesn't take long to install. Increase the file version of the Dll to make sure it gets replaced.
welcome to StackOverflow - it seems to be your first post. I would read this thread if I were you to get an overview of how to implement a WIX major upgrade: How to implement WiX installer upgrade?. Here is another thread (didn't read this one through): How to get WiX major upgrade working?
A major upgrade is essentially an automatic uninstall of the existing version and reinstall of a new version. This is the least error prone update mechanism in Windows Installer. It is the recommended approach to try at first - it works well. A minor upgrade - which is upgrading the existing install, is generally more difficult to get right in the beginning. A number of technical restrictions apply. Here is a very good summary of what is required for a minor upgrade to work (as well as other details): http://www.installsite.org/pages/en/msi/updates.htm
Check out this well known wix tutorial for upgrades and patches. And MSDN.
Since I wasn't a part of my company when our build process was designed and implemented (and has been successful for quite a few years now), I found out that there were things that were being done that may be looked at as 'hacks' to MSI 'purists'. However, in order to get a workable installer with Visual Studio 2012, I've been doing the best I can to mimic what was being done with the .vdproj files in Visual Studio 2010. Of the many snags I've hit, this one seems to be the last one that I can't resolve.
As part of our build process with Visual Studio 2010, we built our code and created a Framework MSI on one VM. Then we took that Framework MSI and installed it on a different VM. After the framework had been installed, we built our product code and created a Product MSI off of it. This created a Product dependence on our Framework. What this meant was that when installing on a client machine, the bootstrapper needed to install the Framework first followed by the Product. On uninstall our documentation stated to either have it handled through ARP or by command line 'msiexec /x {Product.msi/#ProductCode}' and then the 'msiexec /x {Framework.msi/#ProductCode}'.
At the time, management determined that the ProductCode would be the easiest way for other product teams to determine if our product had been installed on a machine. This lead them to the decision that they needed to keep a static ProductCode for both the Framework and the Product.
In order to handle upgrades, they had to create a ProductTool.exe that was nothing more than the msiexec wrapped in an executable that took a /ProductCode={#ProductCode} argument.
As part of our bootstrapper, they called:
Install prerequisites (Windows Installer 4.5, .NET 3.5 SP1, SQL Server 2008 R2 Express, Sync 2.1)
ProductTool.exe (Product.msi -- to uninstall the Product.msi)
ProductTool.exe (Framework.msi -- to uninstall the Framework.msi)
Install Framework.msi
Install Product.msi
However, I didn't discover until just recently that the Burn bootstrapper does not allow REINSTALLMODE=amus. In the install logs, it says that it changes it to REINSTALLMODE=vomus. Apparently in order to get that aforementioned process to work on upgrades, they had to set REINSTALLMODE=amus.
UPDATE: I finally got to talk to the original developer of the installer and found out that REINSTALLMODE=amus was used intentionally to revert all of the versioned files (assemblies, DLL files, etc.) and non-versioned files (.config, SQL script, etc.) as a risk minimization and robustness/"self-healing" strategy.
Having said all of that, is it even possible with a standard burn bootstrap application (BA) to set REINSTALLMODE=amus so that I can get the upgrades working? The MSI files have the Property's set, but Burn seems to override it.
No, this is not supported by the Burn engine today. Burn controls the REINSTALLMODE very carefully to correctly handle upgrades and repairs. Using a in REINSTALLMODE is far from a best practice and thus is not supported. Also, it isn't clear why a is necessary in the scenario you described.
I'm looking for a tool (preferably not InstallShield, and also preferably cheap/Free) that supports Chained MSI Installations. I've got several small installations that need to be able to be deployed separately, but also as one group, and I'd like to not have to maintain multiple installers.
It looks like I need Windows Installer 4.5 to do this properly, but I can't seem to find to much info when I'm looking around for what version of Installer is supported.
The MSI 4.5 functionality is just a set of APIs that allow bootstrapper/chainers to do smarter things for multiple MSIs. You still need a bootstrapper/chainer to install multiple packages. In WiX v3.6 there will Burn.
Incidentally, it used to be possible--although not particularly easy--to "nest" or embed other MSIs into one parent, but it involved tweaking custom actions and such to ensure that the nested programs were removed upon removal of the parent, etc. Sadly, this feature is "deprecated" and thus no longer recommended by Microsoft. Here's how to do it in a Visual Studio installer project... but creating a bootstrapper with WiX would be more advised.
What you need is a bootstrapper. Using and InstallShield or Wix will created an MSI themselves which when that is running will not allow the other smaller MSIs to run. If you already have the smaller MSIs to run a bootstrapper is all you need.
MSDN has a free one you can download that plugs into VS2008 and uses MSBuild to compile. What you will probably need to do is create packages for your MSIs and put them in the bootstrapper as prerequisites. This will allow you to set it up to run them in a particular order.
Here is the MSDN link: MSDN Bootstrapper Manifest Generator
Look at NSIS
I'm trying to find a solution for the following issue:
I have numerous programs (lets call them slaves) that all rely on a single program (master). I need to distribute an installer for each slave. This installer needs to install the master.
I want to be able to version both pieces, so multiple msi's appear to be the right solution, chained with a bootstrapper.
My problem is if a slave installer installs the same version of the master that is already installed, the .msi will run in repair/remove mode.
This is unacceptable from a user standpoint and will just cause confusion.
Is there any way to check for a version of the currently installed fiels before trying to run the msi?
I am currently using WIX's setupbld.exe as a bootstrapper.
Any other solutions greatly appreciated (I have also tried merge modules with no success, since the versioning is useless)
Instead of using setupbld.exe (which I don't really know as I can't find any documentation) you can use msbuild's generatebootstrapper task. The wix documentation already covers how to use this task to generate a bootstrapper that installs the .NET framework. See How To: Install the .NET Framework Using a Bootstrapper. This makes use of the pre-defined bootstrapper packages.
However, in this case you will also have to author your own bootstrapper packages. One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
To determine whether the package needs to be installed, you can use one of the InstallChecks to set a property, and then check the property value in a InstallCondition under the Commands element.
If you're thinking that this is all harder than it should be — I agree, but it's what I've used so far. There are some alternatives which I have not tried yet:
the poorly named dotNetInstaller
which is actually a general purpose
bootstrapper generator.
the wix 3.5 burn bootstrapper which is not yet released. I'm not sure if it is in a usable state yet.