MOTOSHARE 🚗🏍️

Rent Bikes & Cars Directly from Owners

Motoshare connects vehicle owners with people who need bikes and cars on rent. Owners earn from idle vehicles, and renters get flexible ride options.

Visit Motoshare

Heat.exe

General

InstallerGeek created the topic: heat.exe
Hi,
I have some problems to migrate from WIX 3.0.4707 to WIX 3.0.5419 because the arguments of HEAT.EXE changed.
usage: heat.exe harvestType harvestSource -o[ut] sourceFile.wxs What is meant with the new argument harvestSource?
The old command looks like this:
“C:\Program Files\Windows Installer XML v3\bin\heat.exe” dir “..\..\~tmp\j2build3v_win\apps” -gg -sfrag -scom -sreg “$(ProjectDir)..\..\..\~tmp\j2build3v_win\apps\eu” -out “$(ProjectDir)gen_fragment.wxs” -template:fragment How can I convert it to the new implemtation of HEAT?

InstallerExpert replied the topic: Re: heat.exe
Hi,
I have some problems to migrate from WIX 3.0.4707 to WIX 3.0.5419 because the arguments of HEAT.EXE changed.
usage: heat.exe harvestType harvestSource -o[ut] sourceFile.wxs What is meant with the new argument harvestSource?
The old command looks like this:
“C:\Program Files\Windows Installer XML v3\bin\heat.exe” dir “..\..\~tmp\j2build3v_win\apps” -gg -sfrag -scom -sreg “$(ProjectDir)..\..\..\~tmp\j2build3v_win\apps\eu” -out “$(ProjectDir)gen_fragment.wxs” -template:fragment How can I convert it to the new implemtation of HEAT?

InstallerExpert replied the topic: Re: heat.exe
I am in the midst of upgrading our product to be VS 2010 compatible. We’re using WIX to generate a .msi installer. I’ve upgraded to WIX 3.5.1309.0 and have run into a snag.

Specifically I’m having a problem with the HEAT tool in this version. It is having trouble working with our VS2010 converted .csproj files. Votive wants to automatically run this command line:

C:\Program Files\Windows Installer XML v3.5\bin\Heat.exe project “..\..\Common\ArtOfTest.Common.Design\ArtOfTest.Common.Design\ArtOfTest.Common.Design.csproj” -pog:Binaries -pog:Symbols -pog:Sources -pog:Content -pog:Satellites -pog:Documents -ag -sfrag -out obj\Release\_ArtOfTest.Common.Design.wxs

If I manually run this at the command line and point it to the working VS2008 .csproj file I get the expected output file just fine. But if I point it to the converted VS2010 .csproj file (which does compile and generates a .dll in VS2010 no problem), nothing gets output. There’s no error message of any kind either. I tried adding the -verbose switch and that didn’t add any output either. Absolutely nothing comes out (no generated output, no error message of any kind, etc.). Nothing is put in the Event Viewer/Application log either. I am stumped as to why I am not getting any output.

Is there any more information I can give to help? Here is the contents of one of my converted .csproj files (trimmed slightly to hide most of our source code file names):




Debug
AnyCPU
9.0.30729
2.0
{13C244B1-E0E7-41FD-9118-D2CD8A567102}
Library
Properties
ArtOfTest.Common.Design
ArtOfTest.Common.Design
v3.5
512








true
ArtOfTest.Common.Design.snk
3.0.1927.0


3.5

false
publish\
true
Disk
false
Foreground
7
Days
false
false
true
0
1.0.0.%2a
false
true


true
full
false
bin\Debug\
DEBUG;TRACE
prompt
4


pdbonly
true
bin\Release\


prompt
4



False
..\..\..\..\..\..\..\..\..\..\Windows\assembly\GAC_MSIL\ArtOfTest.Common\2.0.8.0__14a0200bfcbb7b62\ArtOfTest.Common.dll


3.0


3.0


3.0



3.5



3.0


3.0



3.5


3.5




3.0


3.0




Component



True
True
Resources.resx




GetString.cs




ResXFileCodeGenerator
Resources.Designer.cs


GetString.cs


DataDrivenPropertyEditorControl.cs
Designer







MSBuild:Compile
Designer
MSBuild:Compile
Designer


MSBuild:Compile
Designer
MSBuild:Compile
Designer


Designer
MSBuild:Compile
MSBuild:Compile
Designer





























MSBuild:Compile
Designer
MSBuild:Compile
Designer


MSBuild:Compile
Designer
MSBuild:Compile
Designer


MSBuild:Compile
Designer
MSBuild:Compile
Designer




False
.NET Framework 3.5 SP1 Client Profile
false


False
.NET Framework 3.5 SP1
true


False
Microsoft Visual Basic PowerPacks 10.0
true


False
Windows Installer 3.1
true





if $(ConfigurationName)==Debug “C:\Program Files\Microsoft SDKs\Windows\v6.0a\bin\gacutil.exe” /i $(TargetPath)

InstallerGeek replied the topic: Re: heat.exe
I’ve found HEAT doesn’t generate any output even for a brand new empty VS2010 C# class library project. Here is what the output window contains when I try to build a simple installer containing only the brand new empty VS2010 C# class library project:

InstallerExpert replied the topic: Re: heat.exe
I see two directories listed below. You should only have one.

“C:\Program Files\Windows Installer XML v3\bin\heat.exe” dir “..\..\~tmp\j2build3v_win\apps” -gg -sfrag -scom -sreg “$(ProjectDir)..\..\..\~tmp\j2build3v_win\apps\eu” -out “$(ProjectDir)gen_fragment.wxs” -template:fragment

Should be:
“C:\Program Files\Windows Installer XML v3\bin\heat.exe” dir “..\..\~tmp\j2build3v_win\apps” -gg -sfrag -scom -sreg -out “$(ProjectDir)gen_fragment.wxs” -template:fragment

OR:

“C:\Program Files\Windows Installer XML v3\bin\heat.exe” dir “$(ProjectDir)..\..\..\~tmp\j2build3v_win\apps\eu” -gg -sfrag -scom -sreg -out “$(ProjectDir)gen_fragment.wxs” -template:fragment

InstallerGeek replied the topic: Re: heat.exe
Is there a particular reason why Heat.exe is targeted and compiled specifically against the x86 architecture? I have seen a couple of questions about this around on the Internet but no firm answer or resolution. I briefly looked over the Heat code (v3.0.5419.0) and there does not seem to be anything specific that jumps out as being 64-bit incompatible. Then again, it was more a cursory glance than a walkthrough.

I am currently migrating our build and development environments to 64-bit. In this process, I’d also like to migrate our current setup projects to MSBuild using the WiX targets and the HeatProject task. I may try my hand at compiling the Heat project for 64-bit process architectures if that’s what it comes down to. Any help before it gets ugly would be much appreciated!

By the way, using a 64-bit version of MSBuild yields the expected BadImageFormatException from heat.exe.

InstallerExpert replied the topic: Re: heat.exe
On 1/13/2010 8:07 PM, Navid Azimi-Garakani wrote:
> Is there a particular reason why Heat.exe is targeted and compiled specifically against the x86 architecture?

Because an MSIL .exe runs as a 64-bit process on an x64 system, so it couldn’t load x86 DLLs. I suspect there’s a need for Heat64.

> I may try my hand at compiling the Heat project for 64-bit process architectures if that’s what it comes down to. Any help before it gets ugly would be much appreciated!
>

Should be pretty straightforward, just get an enlistment.

InstallerGeek replied the topic: Re: heat.exe
Not sure if it is that straight forward. I think the reason we keep punting this feature is the dependencies heat.exe has on the Wix core project (
sourceforge.net/tracker/index.php?func=d…d=105970&atid=642717
).

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x
()
x