The fault, as always with Heat or Tallow trying to extract COM registration
information from DLLs, is typically that your self-registration code doesn't
work properly in the isolated environment created by Tallow/Heat. About all
you can do is debug the code when running in this environment and work out
where it's going wrong.

 

If you can possibly do so, I would recommend that you author the necessary
registration information by hand. Tallow and Heat are intended as one-time
tools to give you a leg-up in creating the WiX source, but after that
original run, you should maintain the source yourself.

 

Frankly, if you're writing your DLLs in C++, you should know how to register
your components. VB6 users have more difficulty as they have less control
over the GUIDs generated by VB. I recommend that VB6 users enable Binary
Compatibility at least between major releases, to keep stable GUIDs while
you have stable interfaces. When changing interfaces you have the option of
continuing with Binary Compatibility if you need compatibility between old
early-bound clients and new components, or Project Compatibility which
allows you to change the interface more radically. (Strictly Windows
Installer requires that new versions of Windows Installer components, and
hence files, are compatible, because it will always replace old files with
new ones, and will always retain newer files when uninstalling, but if
you're not supporting shared installation of the same files, you can get
away with breaking this rule.)

 

-- 

Mike Dimmick

 

  _____  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kirill
Kovalenko
Sent: 05 February 2008 15:58
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] heat.exe generates different output on Vista vs. XP
andcrashes for some DLLs

 

Hello,

 

We've noticed that heat.exe (3.0.3801.0) generates different files on
different host OS. Example files are attached. Could you please clarify if
this behaviour is ok or it's a problem?

 

Also, heat.exe crashes with one of our DLLs. The callstack is included
below.  Shall I open a bug?

 

Unhandled Exception: System.NullReferenceException: Object reference not set
to an instance of an object.

at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.
MutateRegistryValues()

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)

                at
Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Main(String[] args)

 

Sincerely yours,

 

Kirill Kovalenko

Product Manager

Softerra Ltd.

http://www.softerra.com

http://www.ldapadministrator.com

 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to