views:

559

answers:

2

What's the difference between a dll's FileVersion and ProductVersion?

Specifically at runtime, is one used for strong binding, and the other informational?

I'd like to have one set manually, and the other incremented automatically (via our CI build process)

Edit: Richard answered the part I missed in the original question. It's Assembly version that I want to manually control (incrementing with interface changes) while it's File Version that I want my CI system to automatically increment with every build. Thanks.

+2  A: 

Neither is used for strong binding (the version aspect of the full/strong name comes from the AssemblyVersion attribute).

Both file version (from AssemblyFileVersion attribute) and product version (from AssemblyInformationalVersion attribute) contribute to the version resource (as seen in explorer's file properties).

Other than for display/diagnostic purposes, the only real use is by installers to validate a file should be replaced.

Addendum: why would these be different? Answer: Because of versioning requirements. Keeping Assembly Version the same means an updated version (with higher file version) will bind without change. This has a big impact on serialisation (e.g. persisted Workflows).

File and product versions are only likely to be different if the assembly in question is not just part of one product (e.g. a reusable third party library), if just used in a single application there seems little reason not to keep them the same.

Richard
So in practice, why would we want these three to be different? Imo AssemblyVersion should rule, no?
Peter Lillevold
@Peter: good question... expanded with some brief comments, but that really needs a question of its own.
Richard
+2  A: 

Files are distributed as part of a larger project. A file with individual build version x might be distributed as part of project version y.

Joel Coehoorn