What Are the Correct Version Numbers For C#

What are the correct version numbers for C#?

C# language version history:

These are the versions of C# known about at the time of this writing:

• C# 1.0 released with .NET 1.0 and VS2002 (January 2002)
• C# 1.2 (bizarrely enough); released with .NET 1.1 and VS2003 (April 2003). First version to call Dispose on IEnumerators which implemented IDisposable. A few other small features.
• C# 2.0 released with .NET 2.0 and VS2005 (November 2005). Major new features: generics, anonymous methods, nullable types, and iterator blocks
• C# 3.0 released with .NET 3.5 and VS2008 (November 2007). Major new features: lambda expressions, extension methods, expression trees, anonymous types, implicit typing (var), and query expressions
• C# 4.0 released with .NET 4 and VS2010 (April 2010). Major new features: late binding (dynamic), delegate and interface generic variance, more COM support, named arguments, tuple data type and optional parameters
• C# 5.0 released with .NET 4.5 and VS2012 (August 2012). Major features: async programming, and caller info attributes. Breaking change: loop variable closure.
• C# 6.0 released with .NET 4.6 and VS2015 (July 2015). Implemented by Roslyn. Features: initializers for automatically implemented properties, using directives to import static members, exception filters, element initializers, await in catch and finally, extension Add methods in collection initializers.
• C# 7.0 released with .NET 4.7 and VS2017 (March 2017). Major new features: tuples, ref locals and ref return, pattern matching (including pattern-based switch statements), inline out parameter declarations, local functions, binary literals, digit separators, and arbitrary async returns.
• C# 7.1 released with VS2017 v15.3 (August 2017). New features: async main, tuple member name inference, default expression, and pattern matching with generics.
• C# 7.2 released with VS2017 v15.5 (November 2017). New features: private protected access modifier, Span<T>, aka interior pointer, aka stackonly struct, and everything else.
• C# 7.3 released with VS2017 v15.7 (May 2018). New features: enum, delegate and unmanaged generic type constraints. ref reassignment. Unsafe improvements: stackalloc initialization, unpinned indexed fixed buffers, custom fixed statements. Improved overloading resolution. Expression variables in initializers and queries. == and != defined for tuples. Auto-properties' backing fields can now be targeted by attributes.
• C# 8.0 released with .NET Core 3.0 and VS2019 v16.3 (September 2019). Major new features: nullable reference-types, asynchronous streams, indices and ranges, readonly members, using declarations, default interface methods, static local functions, and enhancement of interpolated verbatim strings.
• C# 9.0 released with .NET 5.0 and VS2019 v16.8 (November 2020). Major new features: init-only properties, records, with-expressions, data classes, positional records, top-level programs, improved pattern matching (simple type patterns, relational patterns, logical patterns), improved target typing (target-type new expressions, target typed ?? and ?), and covariant returns. Minor features: relax ordering of ref and partial modifiers, parameter null checking, lambda discard parameters, native ints, attributes on local functions, function pointers, static lambdas, extension GetEnumerator, module initializers, and extending partial.
• C# 10.0 released with .NET 6.0 (November 2021). Major new features: record structs, struct parameterless constructors, interpolated string handlers, global using directives, file-scoped namespace declarations, extended property patterns, const interpolated strings, mixed assignment and declaration in deconstruction, async method builders (via attributes) for individual methods, the CallerArgumentExpression attribute for parameters, enhanced #line pragmas.

In response to the OP's question:

What are the correct version numbers for C#? What came out when? Why can't I find any answers about C# 3.5?

There is no such thing as C# 3.5 - the cause of confusion here is that the C# 3.0 is present in .NET 3.5. The language and framework are versioned independently, however - as is the CLR, which is at version 2.0 for .NET 2.0 through 3.5, .NET 4 introducing CLR 4.0, service packs notwithstanding. The CLR in .NET 4.5 has various improvements, but the versioning is unclear: in some places it may be referred to as CLR 4.5 (this MSDN page used to refer to it that way, for example), but the Environment.Version property still reports 4.0.xxx.

As of May 3, 2017, the C# Language Team created a history of C# versions and features on their GitHub repository: Features Added in C# Language Versions. There is also a page that tracks upcoming and recently implemented language features.

Which version of C# am I using

To get version of framework - look at version of one of main Assemblies i.e.

 Console.Write(typeof(string).Assembly.ImageRuntimeVersion);

Getting version of C# compiler is somewhat harder, but you should be able to guess version by checking what framework version is used.

If you are using command line compiler (csc.exe) you can check help to see version (also you'd need to know Framework version anyway:

C:\Windows\Microsoft.NET\Framework\v4.0.30319>csc /?
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1

Version Numbers float, decimal or double

System.Version

This already stores the different parts, deals with presenting it as a string (revision and build components are only used in display if they are non-zero, so their irrelevance to your case doesn't matter) and (best of all) is already understood by other .NET developers, and won't lead to confusion (if I saw some use of a version number that wasn't a System.Version I'd spend some time then trying to work out why Version wasn't good enough for the job, in case that proved important and hid a nasty surprise. If it was good enough for the job, I'd be irritated at the developer wasting my time like that).

You can deal with the means you want for incrementing easily with extension methods:

public static Version IncrementMajor(this Version ver)
{
  return new Version(ver.Major + 1, 0);
}
public static Version IncrementMinor(this Version ver)
{
  return new Version(ver.Major, ver.Minor + 1);
}

How to check if version number is version between two version numbers

The easiest way is to use the Version class - someone else has already written the logic for you.

var c1 = new Version(major, minor, build, revision);
var sv = new Version(major, minor, build, revision);
var tv = new Version(major, minor, build, revision);

if (c1 >= sv && c1 <= tv) ....

To take your specific example

Ok to make more clear. For example I want to check if version 1.0.44.4736 is between versions 1.0.44.11 and 1.1.0.5.

var c1 = new Version(1, 0, 44, 4736);
var sv = new Version(1, 0, 44, 11);
var tv = new Version(1, 1, 0, 5);
if (c1 >= sv && c1 <= tv)
{
    Console.WriteLine(c1 + " is between " + sv + " and " + tv); 
}

Run it here.

---

If you really want to implement this yourself...

public static int Compare(Version x, Version y)
{
    int result = x.Major.CompareTo(y.Major);
    if (result != 0)
        return result;
    result = x.Minor.CompareTo(y.Minor);
    if (result != 0)
        return result;
    result = x.Build.CompareTo(y.Build);
    if (result != 0)
        return result;
    result = x.Revision.CompareTo(y.Revision);
    return result;
}

Then

if (Compare(c1, sv) >= 0 && Compare(c1, tv) <= 0) ...

Best practices for assembly naming and versioning?

Some good information from this article on Suzanne Cook's blog on MSDN (posted 2003-05-30):

When to Change File/Assembly Versions

First of all, file versions and assembly versions need not coincide
with each other. I recommend that file versions change with each
build. But, don’t change assembly versions with each build just so
that you can tell the difference between two versions of the same
file; use the file version for that. Deciding when to change assembly
versions takes some discussion of the types of builds to consider:
shipping and non-shipping.

Non-Shipping Builds
In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This
avoids strongly-named assembly loading problems due to version
mismatches. Some people prefer using publisher policy to redirect new
assembly versions for each build. I recommend against that for
non-shipping builds, however: it doesn’t avoid all of the loading
problems. For example, if a partner x-copies your app, they may not
know to install publisher policy. Then, your app will be broken for
them, even though it works just fine on your machine.

But, if there are cases where different applications on the same
machine need to bind to different versions of your assembly, I
recommend giving those builds different assembly versions so that the
correct one for each app can be used without having to use
LoadFrom/etc.

Shipping Builds
As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to
work for end-users. Do you want these builds to be side-by-side or
in-place? Are there many changes between the two builds? Are they
going to break some customers? Do you care that it breaks them (or do
you want to force users to use your important updates)? If yes, you
should consider incrementing the assembly version. But, then again,
consider that doing that too many times can litter the user’s disk
with outdated assemblies.

When You Change Your Assembly Versions
To change hardcoded versions to the new one, I recommend setting a variable to the version
in a header file and replacing the hardcoding in sources with the
variable. Then, run a pre-processor during the build to put in the
correct version. I recommend changing versions right after shipping,
not right before, so that there's more time to catch bugs due to the
change.

How do I make automatic version numbers work in Visual Studio

The version numbers that VS generates when you use the 1.0.* syntax are not necessarily going to increment in sequence. The documentation has this to say (emphasis added):

You can specify all the values or you can accept the default build number, revision number, or both by using an asterisk (). For example, [assembly:AssemblyVersion("2.3.25.1")] indicates 2 as the major version, 3 as the minor version, 25 as the build number, and 1 as the revision number. A version number such as [assembly:AssemblyVersion("1.2.")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion("1.2.15.*")] specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is random.

If it's vital that you get versioning exactly right, I highly recommend that you use a third-party solution. The Build Version Increment add-in is excellent.

What you want to do is manage the assembly version yourself. Only increment this when you make a breaking change to the assembly's public interface. Changing this attribute makes your assembly incompatible with other assemblies that reference it, even if you didn't change a thing in your code. Instead, the only thing you want to automatically increment is the assembly file version. Unlike the assembly version, this attribute is not checked by the CLR to determine compatibility.

The Build Version Increment add-in gives you the kind of fine-grained control over what is incremented that you need to get this right. It's what probably should be included in VS to begin with.

Winforms and it's version number

ClickOnce uses its own version numbering, independent from the version numbers in your assembly. Hard to miss in the Project + Properties, Publish tab unless you need to scroll:

---

Related Topics