Duplicate ProgID's Explained

advanced topics | home

Where do duplicate ProgID's come from?

Most commonly duplicate ProgID's come from different DLLs which implement different versions of the same component. As the component version changes and new DLLs are released, sometimes they have the same name and sometimes the file name is different. If you try to add two files with the same name to a project, Manifest maker will ask you to choose one file or the other. If two files with the same name exist in two separate manifests and you reference both of them in your project, there will a file name conflict and Manifest Maker will not be able to resolve this conflict. You will need to make a decision which manifest to remove from the project. Occasionally you may need to rearrange your manifests entirely to avoid file conflicts.

Why duplicate ProgID's in the same DLL?

When a DLL implements multiple versions of a control, it may have multiple classes that reference the same progid. Let us, for an illustration, consider component registration in the registry.

Three classes, with class ID's beginning with hexadecimal digits BAD00001 (2), BAD00002 (5) and BAD00003(8), implement three variations (maybe versions) of the same component. All three version dependent ProgID's, (3), (7) and (9), end with a period and the version number. At the same time all three version independent ProgID's, (4), (6) and (10), are the same -- see highlighted names in the table below.

Ideally, the implementer of the class should remove two of them and leave only one. In real life that is frequently not done. Since registry rules do not prohibit this, the duplicate ProgID's can peacefully coexist even if all ProgID's (version independent and version dependent) in HKEY_CLASSES_ROOT\CLSID are the same.

Windows Side-by-Side changed the rules slightly and requires that there be no ambiguity during translation of ProgIDs to CLSID's and back. When building manifests we need to choose from duplicate values to resolve conflicts. In some cases Manifest Maker is not able to make a decision and you will need to choose yourself. In the case illustrated below Manifest Maker will be able to suggest the best solution based on the reverse lookup (12). It will choose to associate ProgidSample.ProgIDSample with class BAD00003 because the ProgID-to-CLSID lookup (12) points to that class.

Note that values (13) and (14) are optional and only one of them needs to be present. In extreme cases you may see totally inconsistent references. For example from (12) through (13) or (14) to a class that does not even define ProgidSample.ProgIDSample or to a class that does not exist at all in your registry.

(2)  {BAD00001-A057-4836-8ED1-9FC8AEC7741F}
(3)    ProgIDProgidSample.ProgIDSample.1
(4)    VersionIndependentProgIDProgidSample.ProgIDSample
(5)  {BAD00002-D142-4A69-90A5-5307535FA0E0}
(6)    ProgIDProgidSample.ProgIDSample.2
(7)    VersionIndependentProgIDProgidSample.ProgIDSample
(8)  {BAD00003-9388-4882-A753-BBFDF8CCCFD1}
(9)    ProgIDProgidSample.ProgIDSample.3
(10)    VersionIndependentProgIDProgidSample.ProgIDSample

(12)  ProgidSample.ProgIDSample
(13)    CLSID{BAD00003-9388-4882-A753-BBFDF8CCCFD1}
(14)    CurVerProgidSample.ProgIDSample.2
(15)  ProgidSample.ProgIDSample.1
(16)    CLSID{BAD00001-A057-4836-8ED1-9FC8AEC7741F}
(17)  ProgidSample.ProgIDSample.2
(18)    CLSID{BAD00002-D142-4A69-90A5-5307535FA0E0}
(19)  ProgidSample.ProgIDSample.3
(20)    CLSID{BAD00003-9388-4882-A753-BBFDF8CCCFD1}

The example ProgidSample.dll in Manifest Maker Examples directory does not cause Manifest Maker to display a ProgID conflict dialog because the DLL registers CLSID with the version independent ProgID ProgidSample.ProgIDSample (13) and Manifest Maker associates this ProgID with CLSID BAD003.