[wix-users] heat generates different wxs after compiler change of our com dll

[Zoli P]

Ok, it seems the issue is fixed:

there is a bug(?) in wix/heat, in UtilFinalizeHarvesterMutator.cs:

If registry path is in quotes (and this is how VC++2015 standard non-ATL
OLE/COM call COleObjectFactory::UpdateRegistryAll() saves, unlike VC++2008,
where short path is saved without quotes), it cannot handle it.
This case it harvests such registry value: "[#[INSTALLDIR]Bin\OurLib.dll]" -
but the quotes confuses it.

I downloaded latest wix, fixed the code (line 584, in MutateComponents()) a
new "else" branch is needed
....
    else if (registryValue.Value.StartsWith("\"[#",
StringComparison.Ordinal) && registryValue.Value.EndsWith("]\"",
StringComparison.Ordinal))
    {
       parentIndex = String.Concat("file/",
registryValue.Value.Substring(3, registryValue.Value.Length - 5));
       processed = true;
    }
....

I compiled, and overwrote the original WixUtilExtension.dll with the
modified one, and now it seems to work properly.
Thanks all you suggestions.


On Fri, Jul 28, 2017 at 1:54 PM, Zoli P <zoli289 at googlemail.com> wrote:

> Thanks your tip Rob,
>
> RegSpy2 showed the same: same reg keys are created, the only one
> difference is in a value: vs2008 stores path in short format, vs2015 stores
> in long format between quotes.
>
> We are on an older version of Heat (3.0.5210) - that has no source.
> Downloaded the latest, (3.11), that generates the same (good .WXS one) for
> vs2008 dll's, but does not run on vs2015 dll's, fails with a strange
> message:
>
> >heat file OurComLib.dll -srd -suid -out t:\heat_output.tmp
>
> Windows Installer XML Toolset Toolset Harvester version 3.11.0.1701
> Copyright (c) .NET Foundation and contributors. All rights reserved.
>
> heat.exe : error HEAT0001 : Illegal characters in path.
>
> Exception Type: System.ArgumentException
>
> Stack Trace:
>    at System.IO.Path.CheckInvalidPathChars(String path, Boolean
> checkAdditional)
>    at System.IO.Path.GetFileName(String path)
>    at Microsoft.Tools.WindowsInstallerXml.Extensions.
> UtilFinalizeHarvesterMutator.MutateComponents()
>    at Microsoft.Tools.WindowsInstallerXml.Extensions.
> UtilFinalizeHarvesterMutator.Mutate(Wix wix)
>    at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
>    at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)
>
> However, passing other file, like itself (heat.exe file heat.exe  -srd
> -suid -out t:\bin_heat.tmp), it works fine.
>
> Looks heat really does not like vs2015...
> And we also have com visible .net components..don't even want to think
> what would heat say for those
>
> I should maybe start to debug it, or have a look at wix sources.
> Or think about an xslt which will "fix" the wxs for vs2015 dlls.
>
>
> On Thu, Jul 27, 2017 at 9:00 PM, <robert_yang at agilent.com> wrote:
>
>> Another tool you might look into is RegSpy2 - it does something similar
>> to Heat, but initializes the registry with the ATL registrar, and creates a
>> .reg output.  It's a bit obscure, but google should pull up some info.
>> That should allow you to figure out what is actually different between the
>> two DLL's.  You might be able to use that info to correct the problem in
>> your new DLL.
>>
>> I actually haven't dealt with harvesting COM object registrations for
>> years, so I can't say if there has been a recent regression in Heat or not.
>>
>> It might also be interesting to look at the Wix code which does the
>> harvesting: check out \src\ext\UtilExtension\wixext, specifically
>> RegistryHarvester.cs, DllHarvester.cs, UtilHarvesterMutator.cs and their
>> friends ...
>>
>> -Rob
>>
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>
>