Windows installer version 5.0 released long time ago. Will there be any future development on this or Microsoft is going to deprecate it?
I am asking this as we are creating many new installers based on MSI technology. If not MSI, what it's alternative?
Windows Installer hasn't had a roadmap in years. It's not deprecated either though. It just is what it is and still works and is still supported.
There's been a half dozen attempts to replace MSI with the latest being MSIX but all of them fall short of what MSI can do.
MSI is still the best choice for most installers IMO. (Been writing installers since 1997 and MSI since 2003.)
At FireGiant, we've taken to calling the Windows Installer (MSI) the "Anything Installation Engine". It is the only Windows installation technology that is powerful and flexible enough to install anything.
While I'd like to see Windows continue to invest in the technology over more constrained installation technologies, they don't need to.
This fact leads to the sole upside of a stable installation technology: They aren't messing with it. :)
Related
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...
Disclaimer: I've still never gotten beyond the most basic WiX tutorial, because every time I try to understand the concepts, my head starts spinning.
I've been reading Is it feasible/sensible to wrap an InnoSetup installer inside an MSI for easier distribution via AD? :
There is a tool (look for exemsi MSI wrapper) today that can wrap a script/exe based installer, like InnoSetup, and provide install, upgrade and uninstall.
From my experience, that's what users expect: Can install product, newer setups can upgrade it, uninstalling will remove product.
Yet quite a few answers on that question state that only a "true" MSI can reliably provide "all"(?) required(?) features.
So, given that what I always thought an installer was supposed to do is:
Install product with as little hassle as possible
Allow repairing a product (possibly by simply running the setup again)
Allow upgrading of product via a newer setup
eventually uninstall the product, leaving as little trace as possible.
The question is, given that it is proven that, given the right tool, the points above are possible by simply wrapping an exe in an MSI, what additional advantages do "real" MSI packages offer?
To be clear here: An MSI package does (seem to) offer additional benefits for enterprise / AD / GPO distribution, that you don't have if you have a bare .exe installer - I don't question that. What I'm interested in is what - actually used - features are only possible through a "real" MSI package?
MSI supports installing additional features on demand. A shortcut (.lnk) created by MSI contains special metadata recognized by Windows and can automatically repair and/or install missing features.
Another advantage is that non-administrators can install patches without UAC elevation if the package is signed.
Some disadvantages of MSI are:
Cannot create a single .msi for 32-bit and 64-bit targets.
Single user/non-elevated installers can be problematic because the support for this has changed over time and new MSI properties have been added.
Depending on your minimum supported Windows version you might have several major versions of MSI to test/deal with.
Bloats your system drive by storing the full .msi in %windir%\Installer on recent versions of Windows.
Bloats the registry by storing the path and other information about every single file it installs.
Installation or removal operations are by Feature (of a Product). This is not as relevant as it used to be because of the trend toward smaller installers with fewer questions being asked of users. For large installers, for example Visual Studio and SQL Server, questions are asked via bootstrappers--the opposite of what you are considering.
Installation, repair and removal are by Component (across all Product and Version). Reference counting is under the control of Windows Installer and is less likely to become corrupted than the pre-Windows Installer technique. Shared components are now less common because of different application technologies such as .NET and registration-free COM. Large systems might share components but again they might be divided into separate installers so that no Component is needed by more than one Product.
Whether these are advantages depends on the needs of your installation architecture.
MSI supports advertisement of the available application without installing them (more details in this MSDN post). It's handy in a corporate environment as it allows deploying only the most essential applications and 1) saves physical space on user machines; 2) reduce expenses for apps with per-user licensing (only those who really need that app will actually install it and activate the license).
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 started to write an installer with WiX. I've spent several days reading blogs and studying tutorials. Last night I couldn't sleep, so I sat down in Fireworks and drew the following picture. That's my understanding so far of how Windows Installer / WiX work. Is there anything wrong? Do you have any suggestion to complete this graph?
http://nestorsulikowski.com/index.php/2009/08/windows-installer-wix/
I'm happy to receive feedback and modify the diagram so that it's useful to more people.
Firstly, forget about WiX for now. Your concern is Windows Installer - WiX is simply a tool to define Windows Installer databases (MSI files). WiX is no different than many other products out there, except for the fact that it doesn't try to mask any Windows Installer concepts for you. InstallShield transparently does a bunch of things that Windows Installer doesn't support via custom actions and the like, WiX forces you to think more about the Windows Installer methodology and way of doing stuff. Windows Installer is what you want to understand, WiX comes afterwards.
Second, get a copy of The Definitive Guide to Windows Installer. This book is an invaluable resource for anyone looking to understand how Windows Installer (MSI) works.
Third, start with the first entry in the UAC in MSI blog posts, and you should be able to get a better grip on things. It is the best documentation I ever read in trying to understand elevation, permissions and all the other stuff that goes with UAC.
The image kind of makes sense, but I think think the UAC series describes the sequences a bit better. Very few people use administrative installs, and if your installer is written properly then there shouldn't be any reason to concern yourself with advertised installations either. They'll just work. Build your installation to work with only the InstallExecuteSequence to begin with, and then add the UI later and you'll have a bulletproof installation that works without much effort.
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 :)