I am looking for a replacement for InstallShield. Unfortunately we only have 1 license for InstallShield and it was installed on a developer's machine. I'm considering switching over to WiX, but after reading the documentation there is a Product ID GUID, Upgrade Code GUID and a Package GUID.
I also know GUID's were created by InstallShield. If I switch over to WiX can I start using new GUID's or do I have use some of the GUID's created by InstallShield? If an upgrade to a product is released will switching installers hose customers who had the old installer?
In order to be able to upgrade your old package, you need to use (and find out) your old upgrade code.
The Package code should be different (ie autogenerated) for every different MSI (the MSI can be cached with the guid as cache key).
The Product code should be different between major upgrade, but is important for minor upgrades and patches. I haven't used wix to do anything else than major upgrades right now, so I don't know the exact details
See the MSDN article on patching and upgrades as well as the WiX Tutorial
It may also be interesting to know that you can decompile the msi that was generated by Installshield with the dark.exe tool (included in wix). This will recover the upgrade code among other things.
I'd also suggest getting a copy of The Definitive Guide to Windows Installer, I highly recommend the book and don't know how I would have migrated to WiX without it. It's a very low level overview of Windows Installer, if you understand the book then WiX becomes pretty easy.
I know you've already accepted an answer, but make friends with Orca if you haven't already done so.
Orca helped me understand MSI and what WiX was doing under the covers. In your case it would make finding the Upgrade (or any) GUID very easy.
This question may also save you some time and headaches :)
Related
So I'm taking over a pre-existing installer project but I really don't know too much about Wix and installers in general so I am just asking to get an idea what areas in this installer I should look into.
I have this problem where the .msi generated by my Wix installer installs properly. But on Windows 10, the Apps & Features page shows 2 entries for my app as well both of the entries have the "Uninstall" button greyed out.
I'm pretty lost what part of the .wxs is in charge of what shows up in the Control Panel, any help will be appreciated.
WiX Quick-Start: WiX is not trival to learn - there is a learning curve, but it is not rocket science either. Maybe I can suggest this WiX quick start recommentations piece (chaotic, but upvoted - must be helpful). Particularly the "Hello World" section might be helpful - if you don't know WiX.
Answers: With regards to the specific questions:
Failed Major Upgrade: The two entries in Add / Remove Programs generally means a major upgrade has failed so there are now two installed versions of your product instead of one (a major upgrade is technically an uninstall of the old version and install of the new version - under the hood). Here is a long answer on the topic: Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs.
Embedded Setup.exe: It is also possible for an MSI to install a legacy-style setup.exe as part of its own installation. This could lead to several entries in Add / Remove Programs.
MajorUpgrade: To fix the major upgrade you need to look in your WiX sources, obviously. Normally people use the MajorUpgrade element to configure major upgrades (there are more detailed options using other elements). See separate section below for more on this.
Product Code: Whenever you have two versions of the same product installed, you have different product codes for them. To find the product codes, here are some suggestions: How can I find the product GUID of an installed MSI setup? Once you have the product codes you can uninstall via the msiexec.exe command line.
Uninstall: You can uninstall MSI files in a myriad of ways, here is a reference: Uninstalling an MSI file from the command line without using msiexec. Suggest you use msiexec.exe in section 3, as follows:
msiexec.exe /x {Product-Code}
WiX Major Upgrades: WiX introduced a "convenience element" to control major upgrade quite a while back. The idea was to make implementation easier. Here are some details: Majorupgrade or Upgrade ID which is preferred for Major upgrade?
Inlined:
<MajorUpgrade DowngradeErrorMessage="Can’t downgrade." />
As you can see the newer approach is much simpler to deal with, whilst the old one allows full flexibility. I don't know which approach your sources use.
Major Upgrade Technicalities: The key issues for a major upgrade is that the Upgrade Code remains stable (some ways to do it without, but leaving that for now). In addition you need a new product code, a bumped up product version (one of the first 3 digits) and a new package code. If any of these changes fail to be made you can get two entries in Add / Remove Programs (failed upgrade whilst running).
Some Links:
Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs
Old MajorUpgrade Style: How to implement WiX installer upgrade?
Adding entries to MSI UpgradeTable to remove related products
Choosing between upgrade types (minor, major, small) (Installshield content, MSI-generic, not WiX-specific)
Thanks to Stein Åsmul for his link to documentation. I was able to figure out why my msi was doing what it was doing.
The main .wxs was disabling the Remove with the property
<Property Id="ARPNOREMOVE" Value="1" />
So removing that allowed me to Uninstall from the Windows Control Panel again.
The reason why 2 entries were showing up in the Control Panel though was that we were adding a bunch of registry entries in the folder
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\
There's some reasons behind needing some registry entries here, but at least now that I know why I can hopefully work around them. Hopefully this helps anyone in the future that might run into this problem of duplicate entries from clean installs.
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...
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.
We are using Inno Setup and are planning to replace this with WiX. But when evaluating and playing around with WiX, I felt the declarative manner has some limitations compared to programmatic setup solutions.
Moreover I found out that the WiX documentation is rather sparse. So I came across Wix# (WixSharp) which promises to create WiX source code programmatically via script files written in C#.
However we've had some negative experiences with very small companies and even 'one-man-shows'. Therefore I just wanted to ask about your experiences with Wix# (WixSharp) or even other good alternatives out there. Can you report some advantages or limitations?
Wix# looks like an improvingly good bet on the "Will it be around next year" score; see below. And note that Custom Actions are now quite straightforward to build in Wix#.
From this article:
http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX
In July 2014 Wix# was rereleased under more liberal MIT license and it is now hosted on CodePlex.
https://wixsharp.codeplex.com/
In August 2014 UI Extensions to Wix# were released and described in this CodeProject article: "Wix# (WixSharp) UI Extensions".
http://www.codeproject.com/Articles/804584/Wixsharp-WixSharp-UI-Extensions
The fact that new Wix# features are coming out bodes well for the product.
Since Wix# is built on top of WiX and Windows Installer technology, it can only do things that are possible in WiX. When Wix# runs out of gas... WiX can do a lot of things that aren't directly available in the Wix# C# syntax, so you can generally use WiX XML technology directly to bridge the gap. Also see my answer here for additional examples of making Wix# generate the .wxs XML, and then including additional WiX XML code and invoking Candle and Light to build the resulting combined XML into an MSI.
Programatically building an MSI
Below is a quick, non-exhaustive list of WiX and Wix# pros and cons that I have experienced thus far.
WiX/Wix# Pros:
It generates real Windows Installer MSI files.
The uninstall feature is "free"; you automatically get a reliable uninstaller.
The Server Admins in my environment readily accept MSI files for things I as a developer want to install, because they trust the MSI technology and the uninstall feature.
Windows Registry entries are included in the "free" uninstall you get, as long as you create them using WiX or Wix# native syntax and don't merge .reg files--you won't get a registry entry uninstall that way.
WiX/Wix# Cons
Because it's limited to the Windows Installer feature set, some
"procedural" things are harder to do in WiX and Wix#
WiX Pros
Lots of great examples and support resources ("How do I .. in WiX") are available on the Web.
The utilities for harvesting registry entries and putting in XML WiX statements work well.
WiX Cons
As a C# developer, I found WiX XML to be unintuitive to get started
with, working directly with XML files. Wix# and C# made more sense
than WiX at the start.
Wix# Pros
Custom Actions are now simple to implement in Wix#.
Wix# integrates neatly with Visual Studio. I'm currently using it with VS2013.
Wix# and C# made more sense than WiX XML at the start. Better starting point.
Wix# is helping me learn WiX in a more approachable way. Seeing what does and doesn't work in Wix# helps in understanding WiX.
Wix# Cons
Wix# examples are currently a lot harder to come by on the Web. Often it is necessary to research the WiX how-to and then figure out how to apply it to Wix#.
I didn't find an automated path for harvesting registry entries and expressing in WiX# C# code. I translated the .reg file entries manually. It's necessary to have registry entries in Wix# "RegValue(" statements to get the automatic uninstall capability for registry entries.
Note: Developer added this feature in a January 2015 release. I haven't tried it yet.
I will say, doing things in WiX/Wix# that were simple & obvious in procedural installers, like NSIS, and past generation script-based installers (e.g., older Wise editions) often takes extra research and creativity in WiX/Wix#.
Overall, I'm betting on Wix# as a growth technology and a safe bet for current and future use. Worst case, you'd still have your .wxs files, and could change over to using a straight WiX XML approach to building installers, and you'd still be getting value out of the Wix# time investment.
RECENT UPDATES TO THE Wix# Product for Common Installer Tasks
As of January 2015. See: [https://wixsharp.codeplex.com/releases/view/610843][1]
Can now import a .reg registry settings file instead of hand-coding registry class entries
Additional support for Windows Config file modifications
Specific support for Windows Service installations
Support for passing parameter values to Deferred Custom Actions, with all WiX supporting infrastructure properly auto-generated
Support for absolute path in target system directory, with all WiX supporting infrastructure properly auto-generated
WiX has been around for quite a while and has a lot of community support. I've been doing setup (in my spare time :) ) for about 8 years and have never found anything I couldn't reasonable do in WiX.
This is the first time I've seen WixSharp. My first reaction would be how stable is it given it's 0.1.42 at the moment. I'd also be concerned about how much of the MSI schema is actually implemented in WixSharp. It looks interesting, but I'd be more comfortable with an XML file. I don't really see any advantage to do it in C#.
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.