Bad example - AssemblyFileVersion and AssemblyInformationalVersion don't support the asterisk (*) character
If you use an asterisk in the AssemblyVersion, the version will be generated as described in the MSDN documentation . If you use an asterisk in the AssemblyFileVersion, you will see a warning, and the asterisk will be replaced with zeroes. If you use an asterisk in the AssemblyInformationVersion, the asterisk will be stored, as this version property is stored as a string.
Figure: Warning when you use an asterisk in the AssemblyFileVersion[assembly: AssemblyVersion("2.0.*")]
Good example - MSBuild will automatically set the Assembly version on build (when not using the GAC)
Having MSBuild or Visual Studio automatically set the AssemblyVersion on build can be useful if you don't have a build server configured.
If you are using the GAC, you should adopt a single AssemblyVersion and AssemblyInformationalVersionAttribute and update the AssemblyFileVerison with each build.
[assembly: AssemblyInformationalVersion("My Product 2015 Professional")]
Good example - the best way for Assembly versioning (when using the GAC)
If you're working with SharePoint farm solutions (2007, 2010, or 2013), in most circumstances the assemblies in your SharePoint WSPs will be deployed to the GAC. For this reason development is much easier if you don't change your AssemblyVersion, and increment your AssemblyFileVersion instead.
The AssemblyInformationalVersion stores the product name as marketed to consumers. For example for Microsoft Office, this would be "Microsoft Office 2013", while the AssemblyVersion would be 188.8.131.52, and the AssemblyFileVersion is incremented as patches and updates are released.
Note: It would be good if Microsoft changed the default behaviour of AssemblyInformationalVersionAttribute to default to the AssemblyVersion. See Mikes suggestion for improving the version number in the comments here.