1

I have read references that seem to suggest the ability to reference a bind or WiX variable at the command line (this one being the most obvious). This would give me the ability to add the Assembly Information to the name of the MSI that gets generated. For example,

light.exe ... -out Installer.!(bind.FileVersion.myExe).msi ...
light.exe ... -out Installer.!(wix.BlahInfo).msi ...

There is definitely some validation going on. If the WixVariable ID name is different between the WXS file and the reference in the light.exe command, I get an error:

light.exe : error LGHT0197 : The Windows Installer XML variable !(wix.BlahInfo1) is unknown

If I make sure they match, then the error disappears:

<WixVariable Id="BlahInfo" Value='!(bind.FileVersion.myExe)'/>
light.exe ... -out Installer.!(wix.BlahInfo).msi ...

However, no matter what I try, the resulting MSI file never does a run time variable replacement. Instead, it just adds the !(...) to the file name. As an example my last build produced a file with the following name:

Installer.!(wix.BlahInfo).msi

Is this something that can be done or have I misunderstood the documentation? Thanks.

Garet Jax
  • 831
  • 1
  • 11
  • 22

2 Answers2

1

Light doesn't support bind-time variable references on the command line.

Bob Arnson
  • 19,440
  • 2
  • 37
  • 45
1

So I reached the same conclusion as Bob. This wasn't acceptable since it introduced too much variability in builds so I solved it a different way. I knew that an executable run at the command line could reference a Windows environment variable at runtime. So all I needed to do was to set an environment variable and reference it and voila:

light.exe ... -out Installer.%BLAH_VERSION%.msi

To make this happen there was quite a bit that needed to get done. To start, my version number is coming from the Assembly Info of a Visual Studio project. The first thing I had to do was make it dynamic so that it created a new one for each build. Changing the last 2 numbers to a * did that:

[assembly: AssemblyVersion("6.4.*")]

The next thing to do was to externalize that number so it could be used elsewhere. Adding this stanza to the end of the csproj did that:

<Target Name="PostBuildMacros">
  <GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
    <Output TaskParameter="Assemblies" ItemName="Targets" />
  </GetAssemblyIdentity>
  <ItemGroup>
    <VersionNumber Include="@(Targets->'%(Version)')"/>
  </ItemGroup>
</Target>
<PropertyGroup>
  <PostBuildEventDependsOn>
    $(PostBuildEventDependsOn);
    PostBuildMacros;
  </PostBuildEventDependsOn>    
  <PostBuildEvent>setx BLAH_VERSION @(VersionNumber)</PostBuildEvent>
</PropertyGroup>

Thanks to this stackoverflow post for help.

Of course to reference it, I would need to find a way to get an already opened command prompt to update its references to an environment variable. This proved to be the most difficult, but this stackoverflow post came to the rescue.

So now I have tied it all together using a windows batch script. Essentially, I build the EXE, test it, make sure it is good, run my batch script and I have an MSI file named after the assembly info version that was generated for me.

Garet Jax
  • 831
  • 1
  • 11
  • 22