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.
Content developed by: Prabhat Tandon
Content reviewed by: Trevor Fellman