As part of our product install we have a number of COM dlls that we need to
register. These need to be registered for side-by-side usage. My
observations of the DLL's self-registration behaviour is that this simply
means that the default value of each class' InprocServer32 key gets the name
of the DLL instead of the full path (for example: -
[HKEY_CLASSES_ROOT\CLSID\{0B006558-8249-4928-80E8-7351FD0ECDC6}\InprocServer3
2]
@="ExMessage.dll"
"ThreadingModel"="Both"
I'm encountering some problems implementing a solution in Wix:
1. I'm using the Heat tool to generate the registration information, for
example:
<Component Id="cmpB40E30420BD50B58372E3115DBDE4016"
Guid="{4A3B29B8-B561-4B04-A5BA-2A43D811DA13}">
<File Id="filBFD357674D77C489D6AAD13CEDA4F0CC" KeyPath="yes"
Source="SourceDir\ExFileUtils.dll">
<Class Id="{2E77379B-D413-472B-B999-CC6FDFF4F63A}"
Context="InprocServer32" Description="PSFactoryBuffer" ThreadingModel="both"
/>
<TypeLib Id="{F54AA2D4-6BFC-4FAA-8F98-4B392E193A44}"
Description="ExFileUtils" HelpDirectory="CommonComponentsTargetFolder"
Language="0" MajorVersion="1" MinorVersion="0">
<AppId Description="ExFileUtils"
Id="{D0FFAFDF-C88D-4F4B-871F-0B8F700E03D0}">
<Class Id="{9AA853BD-CF38-4CCF-ACCF-AB90B3ECE8EF}"
Context="InprocServer32" Description="ExFileUtils.FileDownload"
ThreadingModel="both" Programmable="yes">
<ProgId Id="Exc.FileDownload.1"
Description="Exc.FileDownload">
<ProgId Id="Exc.FileDownload"
Description="Exc.FileDownload" />
</ProgId>
</Class>
</AppId>
<Interface Id="{3E771802-5FC5-4DA5-B055-D56B7975312A}"
Name="_IFileDownloadEvents"
ProxyStubClassId="{00020420-0000-0000-C000-000000000046}"
ProxyStubClassId32="{00020420-0000-0000-C000-000000000046}" />
<Interface Id="{BBAD2ABA-AD43-4DE9-9773-E215E740FDB7}"
Name="IFileDownload"
ProxyStubClassId="{00020424-0000-0000-C000-000000000046}"
ProxyStubClassId32="{2E77379B-D413-472B-B999-CC6FDFF4F63A}" NumMethods="16"
/>
</TypeLib>
</File>
<Interface Id="{2E77379B-D413-472B-B999-CC6FDFF4F63A}"
Name="IFileDownloadAdvise"
ProxyStubClassId32="{2E77379B-D413-472B-B999-CC6FDFF4F63A}" NumMethods="4" />
<RegistryValue Root="HKCR" Key="AppID\ExFileUtils.DLL" Name="AppID"
Value="{D0FFAFDF-C88D-4f4b-871F-0B8F700E03D0}" Type="string" Action="write"
/>
<RegistryValue Root="HKCR"
Key="CLSID\{9AA853BD-CF38-4ccf-ACCF-AB90B3ECE8EF}\InprocServer32"
Value="ExFileUtils.dll" Type="string" Action="write" />
</Component>
The final RegistryValue element causes a second entry to be created writing
to the class's InprocServer32 key, which subsequently causes Light to fail
with a LGHT0130 error (complaining about the duplicate primary key). This
problem is relatively easy to work around by deleting the InprocServer32
elements. The additional RegistryValue elements do not seem to be created
when a dll that registers its full path is harvested.
2. As written, this code will cause the full path of the DLL to be written
to the registry. I need the filename portion only to be written. There
seems to be an attribute on the Class element which fits the bill -
RelativePath. Unfortunately there seems to be several problems in this area.
First of all, the attribute does not work at all if the class is not
advertised. Light generates the following error: -
error CNDL0061: Cannot convert RelativePath into Registry elements.
Converting the component into advertised creates other problems. The first
is that the shape has to change (all of the elements within File need to be
moved outside). The second is that the advertise attribute then needs to be
applied to every suitable element (presumably both of these issues could be
addressed by XSLT). The third issue is that I encounter ICE45 errors when
attempting to compile such as the following: -
error LGHT0204: ICE45: Row
'{085F48CE-7D17-42C6-8A5D-AACC2D694A87}.InprocServer32.TestComponent' in
table 'Class' has bits set in the 'Attributes' column that are reserved. They
must be 0 to ensure compatability with future installer versions
At the moment I cannot see a reasonable alternative other than to resort to
self-registration (which I fully understand is not recommended). My ideal
solution would be to enable the RelativePath attribute to work with
non-advertised COM components. On the face of it, this does not seem like it
would be incredibly hard. Are there subtleties here which I'm unaware or
have I misunderstood something? Is there another way to resolve this
particular issue? BTW I'm using version 3.0.5419.0.
Thanks in advance for any help,
Nick Hall
------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
