Project.Version Errors

Dec 23, 2014 at 4:33 PM
I am having an issue setting the Project.Version property. I have a version number like this; 2015.0.441.0. If I use project.Version = new Version(2015, 0, 41, 0) in my setup .cs file, I get the following error...

C:_projects\HA CADD.NET\AutoCAD\Source-2015\HA_AutoCAD_AddIn_Setup\bin\Debug_HA_AutoCAD_2015_AddIns_Setup.2015.0.41.0.wxs(3): error CNDL0242: Invalid product version '2015.0.41.0'. Product version must have a major version less than 256, a minor version less than 256, and a build version less than 65536.

If I change the code to project.Version = new Version(15, 0, 41, 0) the error goes away because the Major value is less than 256. I have created installs with the WIX Toolset that have version numbers with the same Major value of 2015 and they will build correctly. I have to suppress the ICE24 validation test for the WIX Toolset to work. It is my understanding that all ICE validation occurs when Light.exe runs so I do not understand why I am getting a CNDL0242 error. Looking through the source code at the Compiler class, I understand how the call to Compiler.BuildMSI works. I can set the --sice:ICE24 option on the Compiler.LightOptions field, but this does me no good because my build never gets to that point. Any Suggestions on how I can bypass this error?
Jan 5, 2015 at 2:55 AM
Apparently this error is due to the MSI limitation ( However it is clear that this limitation can be handled:

I can clearly see that it is candle.exe (not light.exe) who is returning the error. Meaning that validation candle is also a possibility. I googled plenty of references to the same compiler validation error (CNDL0242) but I cannot see why in some cases it is done by candle.exe and in others by light.exe.

Can you please test and see what is the difference in the way the compiler/linker invoked verify by Wix# and WixToolset. The easiest way to do this is to call
var batchFile = Compiler.BuildMsiCmd(project);
This will produce the batch file for building with plain WiX.
Jun 3, 2015 at 9:57 PM
I finally had time to look at this a little more.

In my WixToolset project the Product.Version is set as follows; <Product Version="!(bind.FileVersion.HA.CADD.Revit.Core.dll)"> This syntax is pulling the version number from an assembly being installed in the MSI.

In Wix# I am doing the following:
  Assembly versionAssembly = Assembly.LoadFrom(@"..\..\BuildOutput\Revit 2014\bin\HA.CADD.Revit.BatchProcessing.dll");
  Version assemblyVersion = versionAssembly.GetName().Version;
  project.Version = new Version(assemblyVersion.Major, assemblyVersion.Minor, assemblyVersion.Build, assemblyVersion.Revision);
Using Compiler.BuildMsi(project); I get the CNDL0242 error and the build fails.

Switching to Compiler.BuildMsiCmd(project); I get the following output in the setup.wsx file:
<Product Version="2014.1.26.0">

If I replace the "2014.1.26.0" version string with "!(bind.FileVersion.HA.CADD.Revit.BatchProcessing.dll)" and run the Build_setup.cmd, it builds correctly and produces a setup.msi. Running the install produces an entry for the setup with a version of 2014.1.26.0.

If I examine the setup.msi with orca, the ProductVersion property is 2014.1.26.0. This version is also se in the Upgrade table.
Jun 4, 2015 at 1:40 AM
I have created a work around for this issue by injecting XML into the Product element. Following is the code I used...

Compiler.WixSourceGenerated += document =>
document.Root.Select("Product").SetAttributeValue("Version", "!(bind.FileVersion.HA.CADD.Revit.BatchProcessing.dll)");

I will repost if I have any further issues on this.
Jun 4, 2015 at 2:52 AM
Funny enough the "bind.FileVersion" work around shouldn't even work. According this max value for the version component is 255.

But I am glad WiX guys made the trick available. Though of course it doesn't help if want to set the version without the dll file. I would prefer that WiX allows bypassing the MSI limitation completely and allows setting the version directly: product.Version = FileVersionInfo.GetVersionInfo("MyDll.dll").FileVersion

And you are right the XML post-generating adjustment is the way to go.

You can use also use a slightly lighter syntax for this:
BTW I have added Project extension method ('namespace WixSharp.CommonTasks') which now allows achieve the same with a single call like this: