Understanding GUIDS, updates, and patches with Windows-Installer

Question

I'm learning about Windows-Installer and Wix, and have a number of questions related to how it works:

1. If a component GUID changes, but the same files are in the component, what happens on a major upgrade? Do the files get replaced?
2. If a component is removed from a product, what happens to the associated files on a major upgrade? Do the original files get removed on an uninstall?
3. Am I correct in saying that a major upgrade will replace all files in all components, regardless of whether the assembly version of the file has changed, and that on small updates and minor upgrades, it only replaces a file if the GUID is the same, and the assembly version of the file has been incremented? What if the file doesn't have an assembly version, like an aspx page?
4. Suppose that a product was deployed on a machine without using an installer. If you then created an installer, with files of the same name in a component as what's in the installed directory, what happens to those files if you tried an installation? Are they replaced?
5. Am I correct in saying that if I used a tool like heat to create an xml file with all the files in a directory (like for a website), that you'd have to keep the GUIDs the same (manually or with a script), or you'd only be able to do major upgrades?

Dimidiate

All of this is very easily tested. – Taeniasis

Answer 1

If a component GUID changes, but the same files are in the component, what happens on a major upgrade?

First, the question is whether the old component gets uninstalled. If you don't configure your upgrade to uninstall previous versions of your product, then the component will not be removed (although its files may be overwritten). See also answer to question 2.

Second, the question is whether the new component will be installed. A component is only installed if its keypath is missing. If the keypath is a versioned file, then a lower version also counts as "missing".

Finally, if the new component was marked for installation, and Windows Installer encounters a file with the same name as the one it is trying to install, the File Versioning Rules determine whether the file is replaced or not. For example, a file with a higher version will not be downgraded.

If a component is removed from a product, what happens to the associated files on a major upgrade? Do the original files get removed on an uninstall?

Unless you put the right entries in the Upgrade table and the InstallExecuteSequence that tells windows installer to remove the old product, the old components will be left alone. See this blog post by Alex Shevchuk for guidance on how to create an installer in wix that removes old versions.

Am I correct in saying that a major upgrade will replace all files in all components ...

No. It depends on whether the old component was removed first, whether the new component was installed depending on the keypath, and the file versioning rules.

Suppose that a product was deployed on a machine without using an installer. If you then created an installer, with files of the same name in a component as what's in the installed directory, what happens to those files if you tried an installation?

Again, it depends on whether the components get installed, depending on their keypath, and the file versioning rules.

Am I correct in saying that if I used a tool like heat to create an xml file with all the files in a directory (like for a website), that you'd have to keep the GUIDs the same (manually or with a script), or you'd only be able to do major upgrades?

Correct. The GUID is the identity of a component, so if you would change the GUID there would exist two components (in the old and new version of your product) that installed the same resources to the same target location. And that's a no-no according to MSDN: "Never create two components that install a resource under the same name and target location."

Algae

Answer 2

Learn the Component Rules. They're very easy to break and Windows Installer doesn't enforce them. However if you don't follow the rules, then weird strange voodoo happens.

Easy solution, stick with one file per component and use heat with compile time GUID generation (outputs with Guid="*" uses a stable algorithm, it's not random). Having heat generate GUIDs is random, but GUIDs generated by candle at compile time will be stable (based on filename + path hash or something from memory)

If windows installer finds a file already on disk during install, it will increment the reference count for that file assuming it's a "shared" file. Files are only removed from disk once the reference count returns to zero so if a file already existed, the count may never return to zero and you can get files left lying around even after uninstalling.

Eward

About the reference counting: it's not that simple. If you have two different components that install the same file (a violation of the component rules), then removing one component will remove the file. The file only has some additional protection if it has a "sharedllrefcount", a legacy mechanism that is only updated by Windows Installer if the refcount is already present or if it is explicitly enabled on the component with SharedDllRefCount="Yes". – Algae

True, if you violate component rules then all bets are off ;) – Eward