Mike McGavin
Posts: 38
Joined: 2011-05-31
|
Hello.
I've been using the WiX designer for the first time and despite some looking around the forums it's possible I've missed something obvious regarding the following problem (sorry!).
I have a scenario with a ComVisible DLL, built by another project. Once copied to the system by my installer, it needs to be registered on the system with an equivalent of running "regasm /codebase filename.dll".
I used to be able to do this with the old VS2010 setup projects, despite all their bugginess, by telling the DLL to register via one of the Properties window of the setup project. I've tried something similar in the interface of the WiX designer. In the File System Editor, I've found the primary output for the DLL within the Application Folder, and set its Register property to 'vsdrfCOMSelfReg'.
Unfortunately when I then go to run the MSI that's built, I get a pop-up Cancel/Retry/Ignore warning dialog with the message:
Module C:\Program Files (x86)\Manufacturer\ProductName\filename.dll" failed to register. HRESULT -2147024769. Contact your support personnel.
At first I thought this might be UAC related, even though the installer was already prompting for UAC permission. Based on some previous piecemeal WiX experience I edited the Product.wxs file, and for the Package eleent I made sure the InstallPrivileges attribute it set to 'elevated'. Despite this, and even if I run it with 'msiexec /i installer.msi' from an admin-privileged command prompt (so there shouldn't be any chance of it not having the right privileges by the time it tries to register), I'm seeing the same error.
Is there anything obvious I might be missing? I'm happy to provide more info on request.
So far this is entirely on my development machine. The DLL is compiled with the [ComVisible(true)] attribute set, and I can successfully register it manually with RegAsm. which for what it's worth is running Windows 10, WiX 3.10, WiX Designer v106-b204-std, and Visual Studio 2013.
[Edit/Addition] It seems on this occasion I've actually been using VS2013 (corrected above). I have also since tried upgrading the designer to v107-b205, re-opening the project, switching the Register property in the File System viewer to vsdrfDoNotRegister and then back to vsdrfCOMSelfReg, and recompiled... but unfortunately have the same result when running the MSI.
Also, it looks as if the RegisterForCOM.xml file that's in the XSLT folder of the project merely has an empty COMLibraries element. Should this file have more content if I'm trying to get the installer to register a DLL?
Thanks for any suggestions.
Mike. |
|
Sergey Grischenko
Add-in Express team
Posts: 7233
Joined: 2004-07-05
|
Hi Mike,
The 'vsdrfCOMSelfReg' value is supported for unmanaged dlls only. Please add the following entry to the RegisterForCOM.xml file.
<COMEntry Type="File" Id="_<file ID>" SharedFileId="_<file global ID>" DirectoryId="<directory ID>" Source="<full or relative path to the file>">
<Hidden>no</Hidden>
<KeyPath>yes</KeyPath>
<ReadOnly>no</ReadOnly>
<System>no</System>
<TrueType>no</TrueType>
<Vital>yes</Vital>
<Permanent>no</Permanent>
<SharedDllRefCount>no</SharedDllRefCount>
<Transitive>no</Transitive>
</COMEntry>
E.g.
<COMEntry Type="File" Id="_myfilename" SharedFileId="_A6C7D56E_7EC5_46C4_B7F0_1519CAA95085" DirectoryId="dir_A6C7D56E_7EC5_46C4_B7F0_1519CAA95085" Source="..\..\MyFolder\myfilename.dll">
<Hidden>no</Hidden>
<KeyPath>yes</KeyPath>
<ReadOnly>no</ReadOnly>
<System>no</System>
<TrueType>no</TrueType>
<Vital>yes</Vital>
<Permanent>no</Permanent>
<SharedDllRefCount>no</SharedDllRefCount>
<Transitive>no</Transitive>
</COMEntry>
Let me know if the issue still exists. |
|
Mike McGavin
Posts: 38
Joined: 2011-05-31
|
Hi Sergey.
Thanks for the help, and sorry for taking so long to respond. It's less urgent at this point as I reverted to hacking together a WiX project independently that does what I want. (Basically by using "RegAsm /regfile" and Heat.Exe to generate a heap of XML for registry values to be installed as a component). It'd still be very helpful to be able to use the designer for all of this in future, though, because we often make small .Net components which require registration in this way.
Is what you've suggested documented anywhere at present? I've had a quick look in the documentation PDF and couldn't see anything.
The DLL I'm trying to register is the Primary Output of another project, and I'm having trouble identifying the various ID values which relate to it. I can see what I *think* would be the appropriate File ID in a generated file at "obj\Release\Harvested XML\_[projectName].xml". As this is XML is generated by running Heat.Exe at compile time, though, I'm unsure if I can predict the ID value (prior to compilation) that would be appropriate for going into RegisterForCOM.xml.
Thanks.
Mike. |
|
Sergey Grischenko
Add-in Express team
Posts: 7233
Joined: 2004-07-05
|
Hi Mike,
No, this feature is not documented. It was added to support the conversion of vdproj setup projects to WiX.
The more reliable way is to use RegAsm. However you can use RegisterForCOM.xml as well. To register project output you need to add the following XML to the RegisterForCOM.xml file:
<?xml version="1.0" encoding="utf-8"?>
<COMLibraries>
<COMEntry Type="ProjectOutput" Name="<output name>" Id="_<output name>" SharedFileId="<some id>" DirectoryId="<output name>.Binaries" Source="<path>\<assembly file name>.dll" />
</COMLibraries>
e.g.
<?xml version="1.0" encoding="utf-8"?>
<COMLibraries>
<COMEntry Type="ProjectOutput" Name="MyAddin257" Id="_MyAddin257" SharedFileId="_8271B83C_DE28_4606_A25F_49DEE581A5EC" DirectoryId="MyAddin257.Binaries" Source="..\..\bin\Debug\MyAddin257.dll" />
</COMLibraries> |
|