AssemblyVersion
Where other assemblies that reference your assembly will look. If this number changes, other assemblies have to update their references to your assembly! Only update this version, if it breaks backward compatibility. The AssemblyVersion
is required.
I use the format: major.minor. This would result in:
[assembly: AssemblyVersion("1.0")]
If you're following SemVer strictly then this means you only update when the major changes, so 1.0, 2.0, 3.0, etc.
AssemblyFileVersion
Used for deployment. You can increase this number for every deployment. It is used by setup programs. Use it to mark assemblies that have the same AssemblyVersion
, but are generated from different builds.
In Windows, it can be viewed in the file properties.
The AssemblyFileVersion is optional. If not given, the AssemblyVersion is used.
I use the format: major.minor.patch.build, where I follow SemVer for the first three parts and use the buildnumber of the buildserver for the last part (0 for local build).
This would result in:
[assembly: AssemblyFileVersion("1.3.2.254")]
Be aware that System.Version names these parts as major.minor.build.revision
!
AssemblyInformationalVersion
The Product version of the assembly. This is the version you would use when talking to customers or for display on your website. This version can be a string, like '1.0 Release Candidate'.
The AssemblyInformationalVersion
is optional. If not given, the AssemblyFileVersion is used.
I use the format: major.minor[.patch] [revision as string]. This would result in:
[assembly: AssemblyInformationalVersion("1.0 RC1")]
float
and double
are floating binary point types. In other words, they represent a number like this:
10001.10010110011
The binary number and the location of the binary point are both encoded within the value.
decimal
is a floating decimal point type. In other words, they represent a number like this:
12345.65789
Again, the number and the location of the decimal point are both encoded within the value – that's what makes decimal
still a floating point type instead of a fixed point type.
The important thing to note is that humans are used to representing non-integers in a decimal form, and expect exact results in decimal representations; not all decimal numbers are exactly representable in binary floating point – 0.1, for example – so if you use a binary floating point value you'll actually get an approximation to 0.1. You'll still get approximations when using a floating decimal point as well – the result of dividing 1 by 3 can't be exactly represented, for example.
As for what to use when:
For values which are "naturally exact decimals" it's good to use decimal
. This is usually suitable for any concepts invented by humans: financial values are the most obvious example, but there are others too. Consider the score given to divers or ice skaters, for example.
For values which are more artefacts of nature which can't really be measured exactly anyway, float
/double
are more appropriate. For example, scientific data would usually be represented in this form. Here, the original values won't be "decimally accurate" to start with, so it's not important for the expected results to maintain the "decimal accuracy". Floating binary point types are much faster to work with than decimals.
Best Answer
What's new in .NET Framework 4 Client Profile RTM explains many of the differences:
However, as stated on MSDN, this is not relevant for >=4.5: