Why we shouldn’t use the pre-build event to change the assembly version of a WPF project

Recently, I was working on a support incident where customer was changing the AssemblyVersion  in the AssemblyInfo.cs file through a pre-build event. Even if we don’t change anything in the project, the build was getting fired and version number was changing.

 How does a WPF project build differ?

 XAML differs from most other types of applications in that its build workflow produces a two-part result with dependencies in both directions.  

 (a) Normal assemblies built from the C#/VB code, and

(b) BAML built from the XAML markup.  

 The code refers to the markup in obvious ways, and the BAML stream refers to the code any place where the markup refers to a type declared in your code.    There are checks at build time and at runtime to ensure the two pieces are consistent – the version number is part of those checks.  

 Here is the link which describes Building a WPF Application (WPF)

 If you change the version number through the pre-build event, the build-time check detects the inconsistency and rebuilds the piece that’s perceived to be out of date. In such a case, the task Markup Compilation Pass1 kicks-in.

 This is by design.  It would happen in any type of application that had a similar two-part interdependent build product.

 Here are the guidelines When to Change File/Assembly Versions from the general .Net Framework perspective.

 It’s worth to have a look at Best Practices for .NET Assembly Versioning to decide the versioning strategy and then Incrementing the Assembly Version for Each Build if needed.

Content developed by: Prabhat Tandon
Content reviewed by: Trevor Fellman