For the WiX installer, I am using a managed bootstrapper application (MBA).
In that, for the Major upgrade case, using WiX+Burn setup, Do we need to keep the Component ID same all the time (for all installer versions)?
I am using WiX harvesting to generate a component file programmatically. That will allow us to generate constant/dynamic component GUID. And currently, I am generating a new GUID all the time using GenerateGuidsNow="true".
I observed that, if component GUID for the newer version,
Same as the older version component GUID: after Major upgrade, all binaries/files are placed properly on the target directory.
Generated new component GUID: after Major upgrade, binaries/files are removed from the target directory. (binaries should not be removed)
Questions
What will be the behavior of Component Id for different updates (specifically for a Major Upgrade)? Do we need to keep the same?
If we need to keep the same, then I have to do a major upgrade of one legacy installer and I need to keep the same component GUID with the newer WiX+Burn installer. So is it possible with WiX harvesting to generate a component file programmatically with existing (pre-defined) Component GUID?
Related
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)
I have a Application that is to be installed by two different MSI installers, INSTALLER1 and INSTALLER2.
So can this achieved by keeping same GUID and PATHs.
Use case 1. APPLICATION installed by INSTALLER1 and after some time uninstalled by INSTALLER2, will it notify to INSTALLER1 that it has been uninstalled?
2. APPLICATION installed by INSTALLER1 and after some time upgraded by INSTALLER2, will it notify to INSTALLER1?
Or do need to check other things such as Upgrade code, package code, Component ID should be same( in addition to GUID)
Any pointers will be helpful
I found another post, that I think is your post as well.
Can a single component installed by two different installers, if we keep same GUIDs and Paths for files,services, registries, upgrade codes?
You are using the term 'product' in a confusing manner.
In your other post you reference merge modules, these are a collection of files arranged in components. Your merge module will be consumed by another installation package. There is NO upgrade code for a merge module, there is no package code, or product code either.
If I am understanding your question, if you have configured your components correctly in the merge module, then the component rules will take effect no matter how many products install your application. There is no 'notification' needed.
So, let's say you create your merge module, and the files install to C:\Program Files\MyGreatApp.
MSI_1 and MSI_2 consume your Merge Module 1.0.0.
A customer installs MSI_2, at this time your component information is written to the registry and indicates that MyGreatApp component is version 1.0.0
Later the customer installs MSI_1, at this time when it installs, it notices that MyGreatApp component is already installed and is version 1.0.0, the component will not install at this time because it already exists on the system.
Let's say you release MyGreatApp v2.0.0 and MSI_2 consumes this merge module.
If a customer installs MSI_1, then MyGreatApp v1.0.0 is installed
If a customer later installs MSI_2, the install sees that the component is installed, but the version is 1.0.0, so based on component rules, it has a newer version.
So, from an installer issue, this should honor component rules.
The question you have to ask is that when your app is upgraded from v1.0.0 to v2.0.0, will that cause a break in the code. If your files are compiled separately from the main MSI you should be all set, however, if your files are used as references in the primary application, and this is a .NET assembly that uses strong name key file, you will get dependency not found errors.
I am trying to create a new installer (using Wix) which will going to substitute the current one (InstallShield). Problem is many clients already have the application installed using the current installer. I need my new Wix installer to detect currently installed application perform the update or force the user to uninstall current application before running the new Wix installer.
I am new with creating installers. I need to know which GUIDs (and version numbers) must be the same for the system to know this is actually the same application just a new version. I didn't create the old InstallSheeld installer but I do have access to its code.
Thank you very much.
To uninstall the old InstallShield package, you should find out your old upgrade code and use that within your new WiX installer and do a major upgrade (which will ensure that the old package is uninstalled and removed). Check this Wix Upgrade document for doing the major upgrade.
Since we are on the topic, you can also make use of the Dark.exe to convert the current MSI into WiX source files.
I'm using WIX to create a new installer for an existing product. The installer is very simple - just drops a few dll's into a specified folder on disk.
In the field, my users already have that folder with old dll's in them (since they installed the old MSI - created using a *.vdproj project in VS).
My problem is that after I install the WIX, I have both the old MSI and the new Wix MSI appear in Add/Remove. Expected (? since these 2 are two different kind of MSI's?). I need some kind of an upgrade mechanism - so I was wondering if I can call the old MSI uninstaller from within the WIX one. Or alternately somehow take care of the old Add/Remove entry (a registry hack perhaps?)
Assuming the old install and the new install are installed using the same context ( per-user -> per-user or per-machine -> per-machine ) you can use a MajorUpgrade rule to find the old version and get rid of it. You can do this by syncing up the UpgradeCode property and using a higher ProductVersion or you can do it by authoring a second Upgrade rule using the legacy UpgradeCode GUID.
If the old install was per-user and you want the new install to be per-machine you are out of luck. This isn't supported by MSI. Typically I only support per-machine installs and hardcode the ALLUSERS property and remove the CustomerInformation dialog from the installer UI experience. This is not the default experience for VDPROJ based installers.
My company uses Wix 2.0 in the build chain.
When our users try to install a later build over an older one, the old build is replaced IF the major version number is the same. Otherwise, we let them have a side-by-side install so they can evaluate the new version before buying (no charge for minor version number updates).
However, I'd like to offer the user the choice of replacing any previous version.
From what I know of Wix, this would mean making the OnlyDetect attribute of the UpgradeVersion element dynamic somehow.
Is this possible without a custom action that hacks the table? The msi will be launched from a .exe gui so I can set properties and the like.
You don't want to use OnlyDetect. You author the Upgrade element (or use the helper MajorUpgrade element if using WiX v3.5+) to do the upgrade and then condition the RemoveExistingProducts action. No hackery necessary.