DefineConstants overwrite behavior may cause confusion.

[RichardJFoster]

I believe this is operating "as expected", but the behavior was still slightly confusing, and the current documentation provided no insight.

My goal was to define a WiX constant which mirrored a solution property (as described in the documentation at https://wixtoolset.org/docs/tools/msbuild/#centralizing-msbuild-properties-and-targets).

Per the sample, I defined the project-level constant in a property group with the "Globals" label (in case that was significant), but my constant was not recognized during the build.

After some searching, I realized that it was because I was triggering a debug build, and that a subsequent DefineConstants element in the wixproj file (containing a single "Debug" flag, as introduced by checking the "Define DEBUG constant" in the UI) was overriding the defined constants and removing my project-level one.

This behavior is consistent with other properties in project files - I.e. a "last change wins" scenario - but it still came as an unexpected surprise.

What would have caused less confusion is if subsequent DefineConstants did not override existing items, unless the property name also matched.

[robmen]

What you described is MSBuild behavior. You have to prepend/append Properties manually like:

<PropertyGroup>
   <DefineConstants>$(DefineConstants);Foo=bar</DefineConstants>
</PropertyGroup>

I don't know if the MSBuild documentation describes this behavior or pattern but you could go search their documentation and if not, feel free to make a suggestion to them.

[RichardJFoster]

I understand that, but I was still confused. I hadn't expected to need to jump through that hoop just because a checkbox got checked or unchecked in Visual Studio.

FWIW, even having made that adjustment in the main installation, the property is still not recognized resulting in a WIX0150 error at build time. I'm going to keep poking at it as, for now, there is clearly something I'm missing going on.

I also created a minimal sample (to make sure I was seeing what I thought), which I've attached here. It works more as I was expecting, but if you open it in Visual Studio + Heatwave, go to the "Build" entry in the properties view, and toggle the "Define DEBUG constant" you'll note that the use of the property reference goes away which also seems like it might not be ideal.
WixPropertyOddity.zip

[robmen]

I personally very much dislike the Visual Studio Build Configuration Management functionality. The concept of "active configuration" is very annoying and permeates its way through all things Visual Studio does to project files.

HeatWave follows the convention because it is the "Visual Studio Way". Maybe one day we (FireGiant) will choose to deviate from Visual Studio's behavior and add a checkbox that says "Ignore build configuration and just update my .wixproj without any conditions..." but the implications of such a checkbox would need to be firmly understood first.

I tried your project and checked the Debug box in HeatWave, and the correct thing happened:

<Project Sdk="WixToolset.Sdk/4.0.0">
  <PropertyGroup>
    <OutputType>Library</OutputType>
    <BindFiles>true</BindFiles>
    <ExternalProjectProperty Condition="'$(ExternalProjectProperty)' == ''">.\FilesToInclude</ExternalProjectProperty>
    <DefineConstants>FileLocation=$(ExternalProjectProperty)</DefineConstants>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <DefineConstants>Debug;FileLocation=.\FilesToInclude</DefineConstants>
  </PropertyGroup>
</Project>

These lines were added as expected:

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <DefineConstants>Debug;FileLocation=.\FilesToInclude</DefineConstants>
  </PropertyGroup>

[RichardJFoster]

Ick. If that's the right thing (as far as Microsoft is concerned), then I share your dislike of the active configuration functionality.

My expectation was that the property would not be expanded as a result of the modifications in the VS IDE. I.e. the added lines would retain the $(ExternalProjectProperty) rather than converting it into an absolute value, thereby allowing the actual value to still be injected from the build process.

Thanks Microsoft... :-(

Might it be worth adding some text along the following lines to the "Centralizing MSBuild properties and targets" section? :

NOTE: If you choose to do this, the standard MSBuild conventions apply. For example, if another DefineConstants element is present later in the .wixproj file it may change or remove previously defined values. This is a feature of MSBuild, not of WiX.

[RichardJFoster]

Since it seems WiX is operating "as designed", there seems to be no benefit to keeping this discussion open. Closing it to reduce clutter.