A Brief History of .NET (dotnet)
I recently had the opportunity to work on my first .NET project, which introduced me to the dynamic .NET ecosystem. I was blown when I heard the following statement during our meetings: “We can target our project to .NET Standard instead of .NET Framework to support .NET Core runtime.” Whether you’re new to the world of .NET or simply curious about the multitude of .NET versions, this article is tailored for you.
A Distant Era
Back in the mid-1990s, Microsoft was seeking a competitive edge against the increasingly popular Java. This led to the inception of the .NET Framework — a platform for building and executing applications.
The initial release of the .NET Framework dates back to 2002. It enabled developers to code in any of the 22 supported languages. All these applications would compile into the same intermediate code, executable by the .NET runtime(s).
The Dream of Cross-Platform
While the long-term goal was cross-platform compatibility, the early .NET Framework was confined to the Windows environment. However, Microsoft took the step of open-sourcing the specifications for the .NET Framework runtime and the C# language.
The Expansive .NET Landscape
Equipped with these specifications, developers enthusiastically embarked on creating fresh .NET implementations capable of functioning outside the Windows ecosystem.
This gave rise to the Mono Project, initiated by Miguel de Icaza and Nat Friedman. In 2004, this endeavor eventually led to a version of the .NET Framework that could operate on Linux.
In 2009, the introduction of MonoTouch and Mono for Android allowed developers to craft mobile apps for iOS and Android using Mono. These technologies later evolved into the Xamarin suite of products.
Simultaneously, other third-party .NET implementations like Silverlight and DotGNU emerged. Concurrently, Microsoft was releasing successive versions of the .NET Framework.
Enter .NET Core
At this juncture, developers had access to numerous platform-specific iterations of the .NET Framework for application development. Yet, this necessitated maintaining distinct copies of the application’s codebase for each supported platform.
This complexity was compounded by the proliferation of .NET framework variations.
To address this, in 2016, Microsoft unveiled .NET Core — a genuinely cross-platform runtime supporting Windows, Linux, and macOS. Compared to the .NET Framework, .NET Core was faster and more modular. The dream of a truly cross-platform .NET was finally materializing.
.NET Standard: Partnering with .NET Core
However, .NET Core merely added to an already extensive array of .NET Framework versions. This multiplicity of implementations was a key challenge.
This dilemma was resolved with the introduction of .NET Standard — a set of specifications applicable to any .NET runtime. Consequently, both existing implementations (such as .NET Framework, Mono, Xamarin, etc.) and new ones were required to adhere to .NET Standard to qualify as valid .NET runtimes.
How Does This Benefit Me?
Consider that you’re currently developing a new library using .NET. You can establish a project that targets .NET Standard. This empowers your project to leverage all the APIs defined in the .NET Standard specification.
Consequently, users can employ your library in the .NET Framework runtime, .NET Core runtime, or Xamarin runtime, provided these runtimes conform to .NET Standard. Thus, you’re no longer obliged to maintain platform-specific versions of your source code. Isn’t that remarkable?
What Lies Ahead?
As part of my work, I recently migrated a project from targeting .NET Framework to .NET Standard. In my upcoming post, I’ll delve into the insights I gained from this migration. Stay tuned.
References
Like what you read? From a quick cheer to a standing ovation, clap to show how much you enjoyed this story. Follow to get regular updates.
