What is the 4.0 equivalent to $(project.TargetDir) and $(project.TargetPath) (or how to target them correctly)?

[KnTenshi]

My main issue is that I keep getting "WIX0150 Undefined preprocessor variable '$(project.TargetDir)'." while trying to make a File Component for my installer.

All of my 3.11 WiX installers use those preprocessor variables and they work fine (my stuff also tends to be compact enough that hand writing the Components [rather than using Heat] is no real issue). I've also been able to upgrade a working 3.11 WiX installer to 4.0 and it still has that problem.

Am I messing up somewhere? The Documentation for 4.0 still claims that "$(project.TargetDir)" is valid.

[barnson]

Start with an MSBuild binlog -- it'll show all the preprocessor variables.

[KnTenshi]

Oh, I should clarify that I'm using HeatWave in Visual Studios 2022 rather than the command line version.

[robmen]

You can still build using the command-line MSBuild even if the project was created in HeatWave. That's one of the cool features of the whole system.

[KnTenshi]

Alright, I'll give this a shot on Monday.

[KnTenshi]

Sorry, I got caught up with other things at work. I've been able to make a MSBuild log file, but I'm not sure what to look for (61 kb). Nothing is coming up when I search for "Preprocessor". Forgive my fumbling around in the dark.

[robmen]

Try looking for wix.exe then working up and down from there. The answers are in there. Learning to read MSBuild log files is a great skill to have. Much like learning to read MSI log files is a great skill to have.

[robmen]

The value $(project.TargetDir) is not a valid preprocessor variable in WiX v3. All preprocessor variable names in WiX v3 start with var.. Something very strange is going on in your v3 project if that works.

Also, the documentation you linked to does not show the syntax of $(project.TargetDir) as valid. The only way your example would work (maybe) is if you had a project reference to a project actually named project (all lowercase) like ..\path\to\project.csproj.

[KnTenshi]

Sorry, I had meant to indicate that in 3.11, it was "$(var.project.TargetDir)", but forgot.

And I had originally had it as "$( < project > .TargetDir)" without the spaces, but the preview showed that "< project >" has been removed (I suspect it's some markup swallowing it up). I had also originally had a line at the end to explain that "project" was just a placeholder for my actual project name, but I felt it could be misconstrued as condescending.

And in the Preprocessor variables section, it has the example of

ProjectName.TargetDir	$(MyProject.TargetDir)	C:\source\repos\ConsoleApp42\bin\Release\

Which I took to mean that $([insert-the-name-of-my-project-here].TargetDir) was still valid.

[robmen]

Ahh, too many typos in the original question. Made it look like you didn't understand what was going on. Anyway, it's supposed to still work, and a log file like @barnson suggests will show what is being passed. Building from the command-line or with verbose output on in VS probably will show the -d switches as well.