0

In my WiX 3.5 project I'm including a wxs file via a link. I.e., the wxs file is not in the project folder, it is fairly far away in the folder structure, and is included using Visual Studio's "Add as a link" facility.

This is working fine. But it does have the strange side-effect that WiX creates the obj file for the included wxs in a strange location, creating several folders to somewhat (but not correctly) mimic the path structure between the WiX project folder and the folder where the wxs file is located.

Is there any way to avoid this, so WiX creates this obj file in the same place as the other obj files, or alternatively creates it next to the wxs file, and not half way in between?

quetzalcoatl
  • 32,194
  • 8
  • 68
  • 107
RenniePet
  • 11,420
  • 7
  • 80
  • 106

2 Answers2

2

I always thought this is what -out command-line parameter of candle.exe is for. Have you tried playing with it?

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
  • I've tried this, but can't get it to work. It's true that specifying -out does solve my original problem - no strange folder structure is created. But then I run into other problems. If I specify "-out obj\Debug\" (which one would think is the obvious place) then I get a compile error, saying that references to the dialog I'm including via the link are undefined. – RenniePet Mar 10 '11 at 09:56
  • If I specify "-out obj\" then the compile works OK, but the link step apparently can't find any input. The project "succeeds", but there is no final output, no MSIs. I probably need to tell light.exe to look for its input in the obj folder instead of obj\Debug, but how or where to do that is not obvious to me. (I'm using the Votive MSBuild scripts under Visual Studio.) – RenniePet Mar 10 '11 at 09:56
  • Have you tried -b switch of light.exe? It defaults to the current directory, but you are free to modify it to look for your obj files... – Yan Sklyarenko Mar 11 '11 at 07:19
  • Thank you for your help. I have now gotten it to work, after fiddling with it and pulling my hair out for a while. By the way, the "compiler error" I mention above is actually a light.exe error. Anyway, what I need to do is to put "-out obj\Debug\" on the Compiler settings and "-b obj\Debug\ obj\Debug\IncludedFileName.wixobj" on the Linker settings. – RenniePet Mar 14 '11 at 05:17
  • Damn, I spoke too soon. I've now determined that this "fix" results in MSBuild always doing a build, instead of skipping builds when no input files have changed. For me this cure is worse than the "disease", so I'll go back to letting WiX create the strange folders and just grit my teeth whenever I notice them. – RenniePet Mar 16 '11 at 13:39
  • Hmm, not sure I understood what you mean. If you elaborate on this, I'll try to advise anything... – Yan Sklyarenko Mar 16 '11 at 15:00
  • Yan, thanks for responding. The WiX build projects are part of a whole series of builds, and the intention is that each build is only done if necessary, i.e., if the input files are newer than the output files. I think this is called "incremental builds". Anyway, this normally works - MSBuild skips doing a build if all of the files referenced in the wixproj file are older than the MSI output files. But with the "fix" I indicate above this breaks down - MSBuild does a build every time, irrespective of the relative ages of the input and output files. – RenniePet Mar 16 '11 at 16:08
  • (Incidentally, in my above description of "incremental builds", neglect for the moment the problem of the files referenced by the wxs files - I'm using another technique to take them into account.) – RenniePet Mar 16 '11 at 16:09
  • Strange... it might indicate a bug with light.exe. I would recommend you look through the bug database at sourceforge (http://sourceforge.net/tracker/?group_id=105970&atid=642714) and see if this has ever been reported. If it was, then even if it's not fixed yet, the comments might contain valuable information about how to work it around. Hope this helps. – Yan Sklyarenko Mar 16 '11 at 17:04
1

It turns out this is a bug in WiX 3.5, and has been documented in a blog entry here: http://www.paraesthesia.com/archive/2011/02/07/wix-3-5-2519-0-incorrect-intermediate-object-path-for.aspx

The blog article also helpfully provides a work-around, although it didn't quite work for me. For my situation I had to add an extra backslash to the path, so instead of 

   <ObjectPath>obj\$(Configuration)</ObjectPath>

I needed to specify

   <ObjectPath>obj\$(Configuration)\</ObjectPath>

Thanks to Travis Illig for the blog article, thanks to Edwin Castro on the WiX-Users mailing list for pointing me to the blog article, and thanks to Yan Sklyarenko for his help too.

EDIT:

The plot thickens - it's not a bug, it's a feature!

And it's not in WiX, per se, but in Votive / MSBuild.

https://sourceforge.net/mailarchive/message.php?msg_id=27244936

Anyway, the important thing is that it's easy to fix with the work-around suggested by Travis Illig in his blog article.

RenniePet
  • 11,420
  • 7
  • 80
  • 106