Forexample, theoretically there is one ProductCode for Microsoft Word 2003 and a different one for Word 2007. However both Word 2003 and 2007 would share the same UpgradeCode since you can upgrade from one to the other.
To check and see if a product is already installed on a user's machine you might use MsiEnumRelatedProducts() as above. I think you're asking more than what can be answered in a StackOverflow answer. Consider studying more about MSI:
Additionally to the mentioned clean API way, of course it is possible to detect these codes in the registry too.In some places they are a little bit "changed" this is true, but this is no encryption, only number reordering, e.g. under HKCR\Installer. Quite easy to decipher and I think there is example code anywhere in the net. A 10 liner or so.
It is not recommended to detect applications using their codes, because these can change in the case of updates. If using one, UpgradeCode is safer, because it changes less, but not safe enough. Look for registry paths containing company names and versions of your software!
If you want to do a full update containing all files, do a so-called 'Major Upgrade'.
(There are other possibilities, but this is the most comfortable one, especially for beginners).a) Change your ProductCode for Major Upgrades.
Don't change the UpgradeCode for ANY upgrade, except you want that the new version can be installed in parallel to the old one. In MSI "thinking" then it is a completely new product (better understandable as upgrade path/tree).
Normally don't care about the PackageCode. A good build tool changes it with every build to a random new GUID. To do a an install test with that build it may be necessary to uninstall the old built version first or to know more about MSI (here: Small/Minor Upgrades).
I need a sanity check and some help here. I'm not extremely technical (such as a programming degree) but I'm in charge of the installers for my company. We've been using InnoSetup for over 10 years, and SetupBuilder for 6 years, and I've never had an issue with installing over the product's files with patches or feature updates...until I was tasked with migrating all our product installers over to Advanced Installer (called AI from here).
"Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel."
And I've looked through many forum posts about similar issues, and their answer is the same: I need to change the Product Code. BUT, as I research this outside AI's site, the answer is the opposite: Never change the Product Code unless the changes are major enough to warrant considering it a separate product (like Microsoft Word 2003 to 2007), and don't just change the Upgrade Code for minor or patch updates (because these aren't upgrades to something like a higher edition of our product). AI's support says this is because of Windows Installer not allowing the same Product Code twice, as previously stated, but I'm not installing a new product; I'm installing an update of the same product. All that's changed is some files and the version number (2nd or 3rd segment). And again, no other installer program has had this problem.
So here's my question: How do I work around this so I can just run an older version, newer version, or even the same version and let it overwrite the files? Or if I'm stuck with this, is there a way to always uninstall the detected installation so it can install fresh each time? InnoSetup and SetupBuilder don't even uninstall the existing product, they just overwrite, so I'm vexed by AI's odd paradigm.
If you want one .msi package to be able to upgrade another .msi package just by double-clicking, Windows Installer supports that only with major upgrades, which require you to change the product code and increment the version. Don't let the word major connote size of scope. As I said a very long time ago:
The ProductCode property is a unique GUID used to identify your application. This identifier varies from version to version of the same installer. We recommend using the same ProductCode for each language of your installer : FAQ : Why do I need to set the same Product Code for each language of a package?
Unlike the ProductCode, the UpgradeCode is a GUID representing a related set of products. A set of different versions of your application will have the same UpgradeCode. This enables newer versions of your application to search and upgrade previous versions installed on the same computer.
This is not to be confused with the ProductCode property. Although it is a GUID, the package code is not a property referring to a version of your product. It is more specific than that, meaning it refers to the particular .msi file generated. A new PackageCode is generated each time you build your project. Think of the PackageCode as some sort of checksum. No two .msi files should ever have the same PackageCode unless they are identical.
A common instance in which the PackageCode can be seen in action is when your product has already been installed on the machine. Suppose the user would then double-click the installer again. Windows Installer will check the installer's ProductCode to see if the product has been installed on the machine. Since it was, Windows Installer will find it and then check the PackageCode of the installed product. One of two things can happen:
Should you ever feel the need to use one of your projects as a base for another project, we strongly encourage you to save your project as a template and then open it through the Custom Templates tab.
We strongly advise against starting a new project from a copied .aip project file. This is because the ProductCode and UpgradeCode properties are stored in it. You would then end up working on two products having the same ProductCode and UpgradeCode. When you would then try to install both products on the same machine, you would encounter the error discussed in this article's "ProductCode" section.
Advanced Installer provides you with the possibility to generate new ProductCodes and UpgradeCodes for your project. This can be done through selecting Project->Options->Project IDs. On this tab you can generate new codes for your project. This is an easy fix should you ever find yourself having two projects with the same ProductCode and UpgradeCode.
Our extension offers a FREE version (unlimited time) for creating Simple projects and installers from Visual Studio, seamlessly integrated with Azure DevOps. Unlock even more advanced features by opting for a commercial license, including prerequisites, dialogs editor, and custom actions. You can try these features by creating a Professional or Enterprise project.
Over the last 20 years, Caphyon has created software applications for developers and Internet professionals that are reliable, secure, and easy to use. Our team has been the official MSIX release partner for Microsoft.
Advanced Installer is used for authoring MSI, MSIX and App-V packages or repackaging by a wide user range, from beginners to senior developers and system administrators. Fast and easy to use, it ensures a great ROI for your team as it reduces the time used to create the setup packages, leaving more time for development. For more information, please visit:
Upgrade the standard MSI design and functionality with Advanced Installer's powerful EXE bootstrapper. Deliver an EXE setup package that can handle prerequisites installation, custom UI themes or a web installer experience.This feature is available starting with the Professional edition.
Create MSIX packages from scratch, without writing any code. Leverage Advanced Installer GUI to define your package contents and application configurations. Advanced Installer will automatically generate the package manifest and all the other required resources to build a valid MSIX package.
Easily maintain debug and release builds for your application. Target multiple platforms and package formats from a single source project.This feature is available starting with the Professional edition.
You can configure the check for updates to be triggered using a shortcut, scheduled task or trigger it directly from your application, programmatically.This feature is available starting with the Professional edition.
Get a one-click, no-code integration provided as a separate subscription to monitor your application's installations, crashes, and competitor software evaluations. This feature is available as a separate paid subscription service.
Choose your installer design from over 50 theme templates, with just a click. Use our WYSIWYG editor to customize your installer dialogs.This feature is available starting with the Enterprise edition.
However, in many cases you may already have an installer definition created with a 3rd party tool. Popular authoring tools, like Advanced Installer, InstallShield or Wix, are able to generate a MSIX package out from an installer project, making easier to reuse the work you may already have done to generate MSI installers in the past. Additionally, thanks to these tools, you have the opportunity to use the same project to generate at the same time a MSI and a MSIX, helping you to support customers who might not have migrated yet to Windows 10 and who are unable to use MSIX Core (for example, because it's a consumer application).
What about enabling a CI/CD pipeline in this scenario? In this blog post we're going to see an example on how to achieve this task with Advanced Installer. Why did I choose this product? Well, other than because it's a really good software, the Advanced Installer team has created a task for Azure DevOps which is able to build an Advanced Installer project stored on the repository. And, most of all, the task is able to download the most recent version of Advanced Installer and install it on the machine without requiring any user intervention. This means that we are not forced to create a self-hosted agent where to manually install the tool, but we can leverage the built-in agents provided by Azure DevOps.
3a8082e126