I am seeing the following:
Previously there was:
<Class Id="{myGUID}" advertise="yes"...>
<ProgId Id="MyProgid1.14" Advertise="yes" ... />
<ProgId Id="MyOtherProgId.14" Advertise="yes" .../>
</Class>
This was working fine. When installed, the class had entries for the prog ID
that was first in the list of progIDs that were its children. Each progId had a
clsid that was its class parent. This is what we want.
For reasons I won't go into, we need to now change these entries to
advertise="no" (note that this is even recommended by current WIX
documentation).
<Class Id="{myGUID}" advertise="no"...>
<ProgId Id="MyProgid1.14" Advertise="no" ... />
<ProgId Id="MyOtherProgId.14" Advertise="no" .../>
</Class>
The result of doing this is an error building the MSI saying there are
duplicate IDs in the registry table.
What is happening is that WIX, while turning these ProgIds into their
constituent registry keys, does NOT use the heuristic of "first progID under
the Class element becomes the CLSID\{myGUID}\ProgID key value" that is used
when advertise is yes. Instead it generates:
CLSID\{myGUID}\ProgID = MyProgid1.14
And
CLSID\{myGUID}\ProgID = MyOtherProgId.14
In the registry table, and since the keys are exactly the same (except for the
value written) and belong to the same component, the generated primary key is
the same and you end up with duplicate primary keys in the registry table. Note
that I would expect advertise="no" to behave the same as advertise="yes" (with
the exception of supporting COM triggered IOD) except that the entries end up
as registry table entries instead of entries in the Class and ProgId tables;
however it would appear the conversion is not correct here. We would not want
to see, nor expect to see, the "MyOtherProgId.14" entry in the registry table.
Is this a bug in Wix? Is there a work-around other than tearing down the entire
Class->ProgId hierarchy and converting them into individual registry keys
myself? (Note that I have obviously created a simplified example above in which
doing such a work-around would not be cost prohibitive. In reality my scenario
is very complex with many many classes and many many progIDs across an entire
app suite, so doing that approach would be nearly impossible, and would be
EXTREMELY risky given our current schedule).
--
Bryan
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
