Problems updating modules with the same ComponentId
In my installations there is a certain set of files, which is repeated in different products / versions of the product.
Naturally, I made it as a build file for wix build. The situation was that some of the modules in different installations have the same ComponentId.
It seems like this is allowed, because the products have different ProductId / UpgradeCode, and the components are monitored using the ProductId.ComponentId bundle. This was specifically clarified at one time in one of the Wix developer blogs.
After some time, atypical bugs began to pour in from testers, in most cases a problem was revealed with updating modules from this repeating set.
Those. for example:
product A has a symbols.dll module with version 3.0.2
Product B has a symbols.dll module with version 3.0.2. Both products are installed, first And then B.
An update is released with a new version of the build. those.
in product A - the symbols.dll module with version 3.0.3
in product B - the symbols.dll module with version 3.0.3
Now if you update product B, and then product A.
Then the module in B is completely updated, and in product A remains unchanged.
The installation log says that updating the module is required, but the update does not occur.
Using the method described in blogs.msdn.com/b/astebner/archive/2005/07/01/using-msiinv-to-gather-information-about-what-is-installed-on-a-computer.aspx I got information by product and was surprised.
{E014B150-1444-4641-A21C-DB27C4F3CB40} (shared) (local)
Path: C: \ Program Files (x86) \ companyname \ Product B \ 1.0 \ bin \ symbols.dll
Version: 3.0.3
Owner: NT AUTHORITY \ SYSTEM
Attributes: ARCHIVE
Size: 1722880 Created: 2010 \ 12 \ 01 12:10:10
Changed: 2010 \ 12 \ 01 12:10:10
Component {E014B150-1444-4641-A21C-DB27C4F3CB40} (shared)
Product Code: { AF4A6C3F-E538-403D-A73B-F631B7B0C983}
Name: Product B
Product Code: {70B5C9EF-54D1-4D2C-8440-AB311D730C86}
Name: Product A
Component path: C: \ Program Files (x86) \ companyname \ Product A \ 1.0 \ bin \ symbols.dll
Version: 3.0.2
Owner: NT AUTHORITY \ SYSTEM
Attributes: ARCHIVE
Size: 1721856 Created: 2010 \ 10 \ 29 19:45:52
Changed: 2010 \ 10 \ 29 19:45:52
i.e. modules with the same ComponentId are considered Shared, and the version is compared only with the version of the module from the last installed product. Despite the fact that these are different products placed in different ways.
Putting these modules into “Common Files” is not an option at all, since the situation of installing different versions of products is quite acceptable. I had to make ComponentId different.
Naturally, I made it as a build file for wix build. The situation was that some of the modules in different installations have the same ComponentId.
It seems like this is allowed, because the products have different ProductId / UpgradeCode, and the components are monitored using the ProductId.ComponentId bundle. This was specifically clarified at one time in one of the Wix developer blogs.
After some time, atypical bugs began to pour in from testers, in most cases a problem was revealed with updating modules from this repeating set.
Those. for example:
product A has a symbols.dll module with version 3.0.2
Product B has a symbols.dll module with version 3.0.2. Both products are installed, first And then B.
An update is released with a new version of the build. those.
in product A - the symbols.dll module with version 3.0.3
in product B - the symbols.dll module with version 3.0.3
Now if you update product B, and then product A.
Then the module in B is completely updated, and in product A remains unchanged.
The installation log says that updating the module is required, but the update does not occur.
Using the method described in blogs.msdn.com/b/astebner/archive/2005/07/01/using-msiinv-to-gather-information-about-what-is-installed-on-a-computer.aspx I got information by product and was surprised.
{E014B150-1444-4641-A21C-DB27C4F3CB40} (shared) (local)
Path: C: \ Program Files (x86) \ companyname \ Product B \ 1.0 \ bin \ symbols.dll
Version: 3.0.3
Owner: NT AUTHORITY \ SYSTEM
Attributes: ARCHIVE
Size: 1722880 Created: 2010 \ 12 \ 01 12:10:10
Changed: 2010 \ 12 \ 01 12:10:10
Component {E014B150-1444-4641-A21C-DB27C4F3CB40} (shared)
Product Code: { AF4A6C3F-E538-403D-A73B-F631B7B0C983}
Name: Product B
Product Code: {70B5C9EF-54D1-4D2C-8440-AB311D730C86}
Name: Product A
Component path: C: \ Program Files (x86) \ companyname \ Product A \ 1.0 \ bin \ symbols.dll
Version: 3.0.2
Owner: NT AUTHORITY \ SYSTEM
Attributes: ARCHIVE
Size: 1721856 Created: 2010 \ 10 \ 29 19:45:52
Changed: 2010 \ 10 \ 29 19:45:52
i.e. modules with the same ComponentId are considered Shared, and the version is compared only with the version of the module from the last installed product. Despite the fact that these are different products placed in different ways.
Putting these modules into “Common Files” is not an option at all, since the situation of installing different versions of products is quite acceptable. I had to make ComponentId different.