.NET for the next generation

HKT HKT
Views

It was about a decade ago when Visual Studio .NET 2002 was launched. Having worked with Visual Studio 6 until then, the new interface was refreshing and powerful along with .NET and the suite of languages, tools and technologies. If you were there, you would have felt times were changing. Beyond the cool and modern interface, Visual Studio .NET 2002 had a lot more to offerโ€Š compared to Visual Studio 6 โ€”โ€Š.NET. It was an exciting time for me back then.

You wouldnโ€™t believe me but after having worked with C# for a while and highly impressed, I was thinking maybe some day I (we) would be able to program using C# on other operating systems1. Because .NETโ€Š โ€” โ€ŠCLR, CLS and CTS, were promulgated as a standard (say like the C++ standard) promising platform independence. Implementations that conform to the standard should be able to run applications developed using C#, or any .NET language for that matter, anywhere. Write once, run anywhere. Well, it might seem that it wasnโ€™t all that new if you had been working with C++. Just that C++ is write once, compile every time, run anywhere. It makes a lot of difference.

But as exciting as things wereโ€Šโ€”โ€Š.NET, C#, WinForms etc., Microsoft headed by not-so-bright executives who wanted to keep the market divided and failed to realize that these exciting things were staying out of the real gameโ€Šโ€”โ€Šenabling .NET to go truly cross platform as it was destined to be. Although .NET was born out of a free-mind, it was grown and groomed in the Microsoft-only backyard; no different than COM. As a programmer, I am sure you would understand how this limitation that .NET wasnโ€™t going to be running on other platforms would affect the design and the decisions of any new feature or library or technology. That would leave some strong ties to Windows for a long time (think WPF). Although .NET was still a lot of fun, it is like keeping oneโ€™s joy within and not able to express it. In the past years, I have been programming extensively in Java/J2EE technologies. As a pragmatic programmer, there are umpteen times I have experienced the pain of solving a particular problem the most mundane way one can think of. Had I been programming with C# using generics, LINQ, lambdas or async-await etc., I would have solved the problem in a much modern non-mundane way. It wasnโ€™t just C# language that I missed, it was BCL, CTS, CLR, the debugger, edit and continue, expression evaluation while debugging. I was almost convinced that exciting times had come to an end.

However, Mono, a solo yet bold initiative at the time, backed by Nortel (I think), was an independent implementation of .NET that was cross platform and open sourced. So, either you develop and run .NET applications (console and WinForms, I donโ€™t remember running ASP.NET) on Linux, or run .NET assemblies in Linux that were generated on Windows. The Mono project also provided with an IDE, MonoDevelop, not fair to compare with Visual Studio but it was quite good. Heck, I even developed a WinForms application for running a robot controller application and a command line utility on another occasion. Well, that was for someone who did not know what I was playing with because Mono hadnโ€™t much support. Also the community had not favored it then and so anybody wanting to develop a serious business application would not have considered Mono, even though it was .NET standard compliant; at least that was the idea.

Cross-platform .NET Architecture Diagram
Cross-platform .NET Architecture Diagram

Came this November2, .NET has been restructured, fine grained and undeterred to go cross-platform. Actually, .NET has gone cross-platform. You can find quite a few instances of the .NET components organization picture; Scott Hanselmanโ€™s blog or here right from .NET repository.

Today .NET is componentized fine-grained open sourced and most important_cross-platform_. The monolithic .NET framework is broken down into independent nuget distributable pieces that you can opt in or out to construct customized and application-specific local versions of runtime depending on the nature and needs of your application.

In the last couple of days, I have been fiddling with installing .NET (command line and the installer) on my mac, and writing this post out of total excitement. In about less than a minute, I was able to install the .NET cross-platform packageโ€Šโ€”โ€Š.NET Core (Core CLR, CoreFX, C#, Rosyln etc) and ASP.NET 5 (singular entity that can run against the cross-platform .NET Core 5 or Windows based .NET Framework 4.6) using an installer, yes an installer, like we conventionally install Windows applications (but on a Mac). You can install it manually using command line too. You should have seen my face when I saw the site from the sample ASP.NET application scaffold come up on the browser. It was fun! Actually, the real fun was when Sammy told me that you can run console applications without creating the executable binary. Wait a minute. How could it run without a binary? Enter Rosyln. You can have a bunch of C# files in a folder (say mycs) with a basic project.json file primarily to specify the version of .NET Core and its dependencies or Mono if you like, and you can just dnx run to run your application without creating a binary. Roslyn creates your application binary in-memory and executes off of it. This is the key strategy for running ASP.NET applications too, wherein you donโ€™t have redeploy/restart your web application for code changes. It feels and behave like PHP or Python or any scripting language used in a web application context. I thought I was thrilled with my eyes half rolled up but Scott Hanselman, the programmer charmer, totally blew me away with native binaries (NGEN) for Linux (although it is in development).

There are two more things that are missing in this gameโ€Šโ€”โ€ŠWPF and Visual Studio itself.

  • We need WPF for building rich and modern desktop applications. WinForms can only go so far. It is my opinion that lack of modern cross-platform user interface technology such as WPF led to say most of the editors today that are powered by Node.js, JavaScript and Electron shell. It is a tough game because WPF has strong ties to DirectX and certain windowing capabilities of Windows. However, once WPF is available for developing desktop based user interfaces irrespective of the platform, I believe we will see a shift in the desktop applications development.

  • Visual Studio is another beast yet to make its footprint in the cross-platform world. Needless to say, Visual Studio is the mother of all IDEs, powerful and unmatched when it comes to debugging concurrent applications, multi-language and technology support and recently integration with Roslyn analyzers proving to be intelligent than ever. We need such a beast on Linux or Mac to truly enjoy taming big application development and debugging. Let us hope to see that day when WPF and Visual Studio go cross-platform.

Despite that it seems times are changing again, getting more exciting than ever. I believe we are heading towards an era of modern application development on platforms other than Windows, and not just limited to C#.

Just that opinionated programmers, especially the ones who havenโ€™t written a single line of C# or F# code (let aside Visual Studio), should realize .NET coming out of its bubble and going cross-platform is tread of an entirely kind compared to Java or any other language/technology being cross-platform.

Buckle up!


  1. At the time, Linux was the only other operating system that I had access to. OSX was like grapes in London in the 18th century. ↩︎

  2. Although .NET was open sourced about a year ago, it is now available cross platform with official support from Microsoft. Without that official support, it wouldnโ€™t be encouraging and would be treated another Mono. ↩︎

.NET .net-core corefx cross-platform oss rosyln