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

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.

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.

To elaborate: A.exe with product version 1.1 ships with files B.dll and C.dll. All start out with matching product and file versions. Then someone finds a serious bug in the product. The developer looks at it, and issues a fix that only updates B.dll. Now the product version probably updates as well, to 1.1.1 to account for the minor fix. And B.dll's file version will also be 1.1.1. But A.exe and C.dll didn't change, and so their file version might still be 1.1.

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.

There is one more difference between those two: In file version, you're allowed to use only integers equal or larger than 0 in version parts.

In product version you're allowed to use any text, it will produce warning, if it won't resolve to numbers, but that warning according to msdn is harmless.

Now why would you use not only numbers in version?
Well, according to semantic versioning (semver.org) version looks like this: [Major].[Minor].[Patch] and in patch you're allowed to use:

• pre-release metadata after dash, for example 1.2.1-beta
• build metadata, after plus, for example short hash from git 1.2.1+f0f0f0f