I need to add some files from customer environment into existing msi before installation. In order to do this, We have C# WinForms project which generates transform(.mst) file and add the files in it using .cab. For the new files, new components are created and consistent unique GUIDs are generated too. But, I am not sure if these GUIDS are ok as per Installshield generated GUIDs or MSI technology?
Does Installshield follow RFC 4122 specification for generating component GUIDs? If yes, which version of it?
Also, should I need to handle GUID collisions too?
Recommended Read: Please read this answer on: When to change MSI component GUIDS. A quick search of the MSI SDK found nothing on RFC.
WiX Sources: It turns out RFC 4122 is mentioned in the WiX source code here: Implementation of RFC 4122 - A Universally Unique Identifier (UUID) URN Namespace (one more).
Various GUIDs: All GUIDs in the package must be unique - of course. Component GUIDs should be stable across releases if the file still installs to the same location (why?). The Package GUID should always be new (since it identifies a unique MSI file). The Product Code must be changed when appropriate (for minor upgrades you must use the same product code in the new release) and the Upgrade Code normally stays the same across releases to identify related products / installers. Advanced Installer on GUIDs and an old answer of mine on the same.
Registry Format: Windows Installer requires GUIDs in "registry format" and ALL UPPERCASE LETTERS (see MSI SDK). Below is an illustration using the Create GUID tool from the Visual Studio Tools menu:
WiX Toolset: The WiX Toolset features "GUID auto-magic" and will auto-translate GUIDs found in incorrect formats in your WiX XML markup files to the correct format used inside the compiled MSI.
WiX quick start links.
Links:
https://en.wikipedia.org/wiki/Universally_unique_identifier
Flexera / Installshield: About component, package, product and upgrade codes in Windows Installer
http://www.installsite.org/pages/en/isnews/200012/index.htm
PcaGuidToRegFormat (one more)
Related
Background
WiX & the Windows Installer are completely new to me.
In production, we used an MSI (created using WiX) to install our software. The MSI references a third-party assembly (e.g. OtherCompany.ThirdParty.dll, version 2.5).
The next release of our software must reference an older version of the third-party assembly (e.g. OtherCompany.ThirdParty.dll, version 1.7).
While I understand that installing an older version of a dependency is uncommon, it must happen.
So my question is... how do you configure a MSI (generated by WiX) to use an older version of an assembly without having to completely uninstall the existing package?
Options
We have explored the following:
Increment the assembly's version
it's a third party assembly, and
for traceability this is not an option
rename the assembly
the dependency is being retrieved using NuGet... so this won't be straight forward
force existing install to be completely removed (automatically or manually)
we don't want configuration information that was collected during the previous installation to be lost, so this isn't an option
schedule RemoveExistingProducts before costing
not recommended by Microsoft (see: MSDN)
custom action: to delete dependency
if the installation fails, the application may be left in an undefined state
override file version in setup
moving forward, this will be error prone
changing the REINSTALLMODE
From the articles that I have read, it appears that this should only be used as a last resort.
use a WIX companion file
am still investigating
For Moderators
I am aware that there are other SO posts on this subject. Please note that several of the recommended solutions are incomplete or are error prone.
References
MSDN: Patching and Upgrades
MSDN: RemoveExistingProducts Action
downgrade a library during a msi upgrade
Why Windows Installer removes files during a major upgrade if they go backwards in version numbers
MSI Writing Guidelines
What Every Developer Should Know About MSI Components
Windows installer deletes versioned file during product upgrade, instead of downgrading it
MSDN: Windows Installer - File Versioning Rules
Msiexec REINSTALL=ALL REINSTALLMODE=vamus not reinstalling anything
good overview of what is happening under-the-hood
Forcing an upgrade of a file that is modified during its initial installation
this is an older post is from 2009
Some issues are best solved by the application design rather the deployment.
There are two places to save a particular version of a .NET assembly: the GAC or the application folder (or subfolder with probing privatePath). In either case, you might want to use a bindingRedirect.
Also, you can load from a specific location using AppDomain.AssemblyResolve, provided the binding is not successful using the GAC.
General Reference: How the Runtime Locates Assemblies—thanks to #Pressacco.
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...
General Information:
We use WIX 3.10.3 to build both our Base Msi and Patch Msp.
Supports Windows Installer version 301
Patch is build using Purely Wix method as documented.
Root Cause for the issue:
Base Msi contained a file named "Sample.dll" with version as 1.0.0.0 and language as "neutral".
While building patch, WIX considered there was change to the contents of Sample.dll but the version is retained as "1.0.0.0" and language as "neutral".
Sample.dll used for Patch creation, even though there was no change to the contents but some how we were able to identify there was binary change when compared with the base and the msp dlls used for creation. Refer below screenshot from Beyond Compare
Beyond Compare Snapshot of the DLL's included for MSI and MSP
During installation of Base and then patch, as per Windows Installer File Versioning rules(https://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx), the file "Sample.dll" was not re-installed by patch since the version and language are same.
Hence while removal of patch, windows installer requested the source of the msi.
This is causing uninstallation failures at our customers as the sources of the msi are not available during uninstall.
Here's a blog entry which said this issue is identified in Windows installer version 301 (https://blogs.msdn.microsoft.com/heaths/2007/06/28/unchanged-files-break-patch-uninstall).
We had already tried updating the installer version support to 405 in WIX and still the problem occurs.
Here the patch creation considers the Binary change between the base msi and patch msi to create the Msp whereas windows installer considers File versioning rules while installing.
Is there some changes that could help avoid such scenarios and how to ensure that only really changed files are considered for patch creation and installation?
I am writing a utility for our lab that checks the installed software on the local machine against a collection of installers (msi files) on a NAS. From a bit of web searching, it seemed like the preferred approach for determining what packages are installed on a Windows based machine from within code is to iterate over the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall keys. The installers that I am interested in are namespaced ( and created by me) so picking the registry keys that I am interested in is easy, but I have noticed the installers that I have created using wix are not setting the InstallLocation key like most of the other installers are doing.
Since I am not specifically setting any of these keys (within the Uninstall\XYZ section) within the wix installer specifically, I am assuming there are some installer attributes that are being used to populate the existing keys. Does anyone know the proper way to have the InstallLocation filled out by the wix installer? I am currently using WIX 3.8 at the moment.
This would be a place to look if you are creating the MSI files:
http://robmensching.com/blog/posts/2011/1/14/arpinstalllocation-and-how-to-set-it-with-the-wix-toolset/
If they belong to other companies there's not much you can so.
When products A and B each install several MSIs and some of the MSIs are the same, will uninstalling either A or B affect the other? Does install location matter?
Also, what happens when common MSI C's version is higher in Product B and B upgrades C on install? Now uninstalling B will remove the common MSI C which breaks Product A. How do you handle this gracefully without using the Permanent flag?
The first thing that comes to mind with this question is whether the products in question are decomposed the way they should be.
As a general rule all MSI files think they own whatever they install, and they will uninstall everything attached to a component GUID inside the MSI on uninstall if the reference count (number of products using the component) is zero.
There are some qualifications to this rule:
If the component is marked permanent it is never uninstalled
If the file / registry item has no component GUID at all, it is installed, never tracked by Windows Installer, and won't get uninstalled either
Finally the reference counting for MSI allows the same component to be shared between several products and it will persist on disk during uninstall if it is registered in use by several other installer packages
The mechanisms for creating shared components between MSI packages are generally:
Merge modules allow you to install shared components that are reference counted and that will remain on disk after uninstall of a related product if there are other clients using the GUID on the system. A merge module is merged into other MSI packages at compile time. A form of binary early binding if you like. It can be merged into any package.
With the advent of Wix (xml based installer source files), it is possible to include the same segment of files from several setups via an XML source include file instead of a merge module. This is vastly superior in my opinion due to the fact that Wix works better for source control (see Wix link for explanation). It is crucially important to realize that a "Wix source include file" has the exact same effect as a merge module - its components are reference counted properly for sharing between different installer packages, provided the GUIDs in the source file are hard coded (I recommend not to use auto-generated guids for this particular purpose). It is my personal opinion that you should use third party merge modules for generic runtime files, but only Wix includes for your own shared files. Merge modules are harder to manage than Wix includes imho.
Updating and file replacement:
As to update scenarios the MSI file replacement rules will take care of updating newer files, dependent upon the overall setting in the special Windows Installer property REINSTALLMODE.
In general higher version files overwrite lower version files. Non-versioned files are overwritten if they are unmodified. If they are modified the create and modified date stamps are different and the file is left alone.
Keep in mind that the issue of downgrading files is actively discouraged by the overall MSI design. If you need to downgrade files (shared or not), there is something deployment smelly about your design.
At this point I would thoroughly read these answers:
Windows Installer and the creation of WiX - for a short Wix history and context
Change my component GUID in wix? - for component reference counting
Wix installation, server, client or both - for client / server packaging
Wix to Install multiple Applications - for changing requirements and setup problems
WiX tricks and tips - for community Wix tips and tricks
How to include wxi file into wxs? - for a simple idea of how to deal with Wix include files
Provided you use Wix, or you are willing to use Wix, I would think the best way to deal with your overlapping products would be to decompose your installer into Wix segment source files that you include as needed in your main installers. This will allow the uninstall of one product to leave in place any components used by other applications.
With that being said, I do not like to cause too many overlapping dependencies in my installers for the reasons listed in this article (also listed above): Wix to Install multiple Applications .
For stability it is crucially important that shared components are stable before being used by too many setups as a bug fix as a general rule will require the recompilation of all setups the shared component is compiled or merged into. The easy way to say it: bundle files together that change together.
To counteract this need for massive recompilation, you can chose to deliver a stand-alone supporting setup consisting of some of the shared components. One, or a couple of such "shared components setups" that are likely to contain Wix includes that change together on a similar, slow release schedule, and then separate setups for each product should be able to account for any deployment need whilst maintaining a balance between maintainability and flexibility.
The product setup should then be the one that gets recompiled often, and the shared modules setups should be designed for minimal recompilation. Then wait for changing requirements :-).
To me it is all about cohesion and coupling, and the difficulty of balancing sales, marketing and technical needs.
If Product A and Product B has a MSI C in common then
If Product A is installed, also MSI C is installed, now when Product B is installed MSI C will not be installed since its already available in the system (if Product B is WiX Burn based, it registers a dependency). In case of uninstallation reference counting is automatically handled if Product A and Product B is WiX Burn based installer or any other Bootstrapper which supports reference counting else MSI C is removed along with Product B.
even I was looking for the answer of the above question, but in Wix v3.7 and higher, the MSI packages are automatically reference counted by the Burn engine. I have tested this, and works perfect.
The same can be checked in Rob's blog