The .NET of Tomorrow

Exciting times lie ahead for .NET developers. During Build, Microsoft’s biggest developer event of the year, clear roadmaps were given on the future of .NET and C#. Microsoft is re-positioning .NET to be a platform that can be written anywhere and run anywhere, which is a departure from it’s long history of proprietary technologies.

Microsoft is also reinventing itself in other ways too, like its developer tooling and the way it communicates with developers in general. This more open nature of Microsoft has even started to win over even the most skeptical of developers, such as my co-worker Cody Lindley, which you can see in his latest article, “What Has Microsoft Done For You Lately?”.

So what does all this mean for .NET developers? A well thought-out roadmap from Microsoft showing the strategy for the future of .NET. In this post, we’ll take a look at what that roadmap is.

Frameworks and Libraries

The state of .NET today is a little scattered. Restructuring projects always seem to make them worse before they get better, and this is no different. The road ahead has been a bit fuzzy since the introduction of .NET Core and perhaps got a little fuzzier with the recent announcement adding Xamarin to the mix.

While these are exciting times, they are unclear and uncertain for developers.


.NET Today

With the current structure of .NET, creating code that spans across different Microsoft platforms means working with portable class libraries (PCL). The PCL has shared functionality, but is very limited when compared to the .NET framework and understanding how the PCL is supported on various platforms is less than straightforward. In addition, working across the complete .NET ecosystem means working with up to three different base libraries: Base Class Library (.NET Framework), .NET Core, and Mono Class Library (Xamarin). Developer fatigue really begins to set in when trying to grasp which APIs are available for a given scenario.


.NET Tomorrow

Thankfully Microsoft understands the issue at hand and has a clear vision of how .NET things will work in the .NET of tomorrow. A big part of this strategy is to deprecate the PCL and replace it with a contract for common API support. This new contract will be called the .NET Standard Library. The .NET Standard Library will also include a specific set of reference assemblies that all .NET Platforms must support, known as the .NET Platform Standard.


The .NET Standard Library decouples the application models from the base libraries and tooling. This decoupled scenario allows for better code reuse and a shorter learning curve. Having a decoupled approach also means that the .NET Standard Library can be updated with less friction (aka breaking changes), this will mean more innovation at a faster pace. As the .NET Standard Library API surface increases with newer versions, some platforms will be left behind and become legacy. The upside is that new and yet to be created platforms have a clear foundation to build upon.

With the following table it’s easy to see that an ASP.NET Core 1.0 application has access to the full .NET Platform Standard version 1.5 APIs. In the same regard, Windows Phone 8.1 would not have access to APIs added to the standard after version 1.2.

Target Platform Name Alias
.NET Platform Standard netstandard 1.0 1.1 1.2 1.3 1.4 1.5
.NET Core netcoreapp 1.0
.NET Framework net 4.6.2
Universal Windows Platform uap 10.0
Windows win 8.1
Windows Phone wpa 8.1
Windows Phone Silverlight wp 8.1
Mono/Xamarin Platforms *
Mono *

The Language of the Future is C#

Since C# is the most popular language in .NET, it’s necessary to include it in the conversation. While C# is a very mature language, it has an exciting future as well. Much like the .NET framework, C# is being developed as an open source project. Now that C# is open source, its development will be visible to the public, including the roadmap.

C# 7 and beyond

Much like with the .NET Standard Library, Microsoft is promising a faster release cycle with C#. These out-of-band releases will include new language features to further enhance an already robust and mature language. In future releases we’ll see some interesting new ways for developers to write C#.

  • Local functions will allow functions inside of methods that will have access to variables in scope.

  • Tuples let functions return multiple results. The results can be named so that the code remains readable.

    //Local function and Tuples preview
    static void Main(string[] args)
      int[] numbers = { 1,2,3,4,5 };
      // Local function
      (int sum, int count) Tally(IEnumerable list)
        var r = (s: 0, c: 0);
        foreach (var v in list)
          r.s += v; r.c++;
        return r; // return Tuple of (int:sum, int:count)
      var t = Tally(numbers);
      WriteLine($"Sum: {t.sum}, Count {t.count}"); // => Sum: 15, Count: 5
  • Pattern matching extensions for C# enable many of the benefits of algebraic data types and pattern matching from functional languages, but in a way that smoothly integrates with the feel of the underlying language. Pattern matching is able to switch on the type of data and offers greater flexibility when working with non-primitive data types.

    // pattern matching in C#
    var people = {
                  new Student("Dustin", "Campbell", 195434) { Grades = { 4.0m, 4.0m, 3.9m, 4.0m, 3.8m, 4.0m }},
                  new Student("Mads", "Torgersen", 193845) { Grades = { 2.0m, 2.4m, 3.4m, 1.8m, 3.9m, 0.2m }},
                  new Student("David", "Stephens", 230954) { Grades = { }},
                  new Professor("Anders", "Hejlsberg", "Programming languages"),
                  new Professor("Scott", "Guthrie", "Clouds"),
                  new Professor("Scott", "Hunter", ".NET")
    foreach (var p in people) 
      if (p is Professor { Subject is var s, FirstName is "Scott"})
        WriteLine($"One of the Scotts is teaching {s}");
      if (p is Student { FirstName is var n, Gpa is decimal g})
        WriteLine($"{n} has a GPA of {g}:N2");
  • Immutable objects are a feature being discussed for beyond C# 7. Immutable objects are an explicit shorthand way of writing immutable classes with the added benefit of the compiler being able to identify them as immutable.

    // new up an immutable object 
    var p1 = new Point { X = 3, Y = 7 };
    // copy p1 to p2 with an X value of negative p1's X value.
    var p2 = p1 with { X = -p1.X }; //=> { X = -3, Y = 7 }


The write anywhere run everywhere strategy of .NET is really apparent with C#. Because of Roslyn, the cross platform compiler as a service, C# can be written and run on any platform. Roslyn enables C# to run in IDEs and editors and opens the door to support from any linter, refactoring tool, and code generation tooling. In the future, expect to see more uses for C# in more places.


.NET is always changing and improving as a platform. Because of the sheer amount of changes happening and the speed at which they are delivered, expect some difficulties along the way. However, gone are the days of Microsoft secrecy, so enjoy the new open development process and transparent roadmaps that have been outlined. There’s an exciting future ahead for .NET, it’s cross platform, open source, and full of features one would expect from a modern set of tools and languages.

The .NET of tomorrow is powered by .NET CLI. Check out our whitepaper, The Command Line: Reinvented for Modern Developers to learn how the CLI enables cross-platform development.

Images courtesy of Microsoft


  • Pingback: Dew Drop – April 25, 2016 (#2237) | Morning Dew()

  • trisys

    Thanks for posting this article, but as a veteran developer (learned ‘C’ in 1984), do we really need C# to evolve as a language? Can Microsoft deliver on wider adoption of cross-platform C# whilst at the same time continually evolving the language? Are we not heading for versionitis here?

    • Ed Charbeneau

      I feel that the strategy is to add more ways to attack a problem and for those that understand the new language features write less code to do more. The changes required to make LINQ possible in C# have really left a lot of potential in the language for functional programming, I’d like to see them continue to improve this with immutable objects.

    • Carlos Pérez Chávez

      I really want a stable language not the flavor of the week. C# has proven to be a reliable language. I hope it stays that way for many years.

    • I think you’re forgetting who’s at the helm here – these aren’t the guys writing Swift where one day you have a foreach loop and the next day you don’t.
      What I’m saying is: You can still write C# 1.0 code in C# 6; in this way, if you choose not to learn/use new features you’ll be just fine. And I’d be willing to bet that if/when they add performance improvements to the language as part of a new feature, it’d bleed in to older paradigms where applicable (eg: local functions -> lambdas -> delegates)

      I think Ed’s right on w/ his response – they’re providing more ways to attack problems and also providing a lower barrier to entry to those familiar with other language concepts that don’t (yet) exist in C#

      • Ed Charbeneau

        I agree. The language isn’t “changing”, it’s being added to. Nothing is being removed from it.

        • trisys

          But if someone adopts some new C# features to build a large code base, then wishes to port that onto an older platform, and finds that they are not supported, then what? Who is guiding this poor soul to prevent him falling into that trap?

          • Paul Taylor

            The same can be said of literally every development language. In such a case, an up-to-date development platform would be required, with the resulting application being deployed onto the older platform. If you don’t want to update the libraries on the older platform then you’d need to restrict yourself to earlier versions of the .NET library – probably a bigger challenge than a few language updates that generate the same IL code anyway.

          • trisys

            It wasn’t with ‘C’ where the design goal was to create a minimal, portable language. Look at the mess created by C++. I hope C# (or the community) does not repeat those mistakes.

  • Byron

    The only problem with C# adding all these new features is that it makes other languages seem increasingly primitive and hard to use. Can’t wait for Tuples, local functions and compiler supported immutable objects. Pattern matching is cool too, but the ‘Field is Type X’ syntax still seems a little off to me.

    • Paul Taylor

      Agreed – that syntax looks too much like VB rather than C#.

      • Ed Charbeneau

        What’s great is they are accepting community feedback now via GitHub.

  • Miki B

    Hi Ed,
    i read with interest your article.
    I’m a old VB and VBA developer and after many year on Delphi i want to start a project with .NET, because in Italy is much more simple find a programmer that Delphi programmer if i need help.
    In his article i read that WinForms is still alive, it’s true?
    For my project Winforms is faster to implement and is enough powerfull.
    Can i start with WInforms o is better to pass to WPF?
    Thanks in advance

  • MBR

    I’m not sure why C# is the “language of the future” when all of these features (and more) have been around forever in F#, and there’s nothing stopping anyone from using F# (or mixed with C#) today — especially when these features look like they’re being implemented in C# in a way that is so unnecessarily verbose that it takes away much of the point of having them in the first place. (Tuples are ordered and don’t have named fields, matching should use type inference so that the class name and/or most of the field names should not be necessary, “new” should be optional in construction, etc.) And hopefully local functions can use the => syntax to avoid the need for the braces.

    • Radu Popa

      Right on!
      Problem is, what would be C# without braces and semi-colons?

  • Pingback: The week in .NET – 5/3/2016 | .NET Blog()

  • Pingback: My readings in 2016 week 17 | My path to become awesome dev()

  • Michael Rockwell

    I have been programming for nearly 40 years and still enjoy it every day because of .Net and C#. I have been developing and advocating for Object Oriented development since the late 1980’s and am so glad that Microsoft validated the OO with .Net in 2001 and has been evolving the computer science to make other concepts like generics, collections, lambdas, immutable memory, etc. mainstream. The way that I code and think improves everyday because of the great work that Microsoft does to enable these capabilities. Having more tools and ways to express logic in concise and consistent ways allows for more work to get done easily. The new work to increase the reach of .Net across more platforms is very exciting.