It’s been 17 years since Microsoft unveiled its .Net strategy at its Forum 2000 event. Although the resulting marketing blunders led to some confusion about exactly what .Net was—the name turned up on both servers and applications—the underlying development tools become the heart of Microsoft’s engagement with enterprises around the world. .Net has also grown beyond the Windows ecosystem, bringing Microsoft tools and technologies to iOS, Android, and now Linux.
But that growth has led to a new set of questions: Which .Net should I be using—.Net Framework, .Net Standard, Xamarin’s Mono (and the closely related Unity 3D gaming tools), or .Net Core?
With four sets of libraries and a trio of runtimes, it's harder to choose the foundation for your .Net applications. Recently that question became even more complex because it’s no longer only a choice of the languages you use. That means the future development of the .Net languages is going to diverge, which means some .Net languages won’t be able to run on some .Net environments.
When using .Net, you have to work through much more than languages used. You now also have to work through the .Net runtime you’re targeting. For much of .Net’s history, you’ve only had to deal with one runtime, the .Net Framework. It’s grown with Windows and the rest of Microsoft’s platform, adding new language features and more and more APIs. As a result, it’s now part and parcel of the wider Windows ecosystem, from IoT to the cloud.
But now there’s more choice, as is evident in the new installer for Microsoft’s Visual Studio 2017. When it comes to writing C#, F#, or Visual Basic, there’s now a wide selection of .Net variants and a wider-still selection of platforms for you to target. That’s not a bad development, and making .Net a cross-platform runtime was one of its original aims, though one that initially was lost as Microsoft tried and failed to beat Flash at its own game with Silverlight.
What’s interesting about the Visual Studio installer is the prominence it gives to the latest member of the family, .Net Core. It’s front and center, right there in the Workloads section of the installer when you choose to build ASP.Net web applications or when you want to work with cross-platform applications using containers. Featuring .Net Core is a big commitment to taking familiar Windows development tools into the wider Microsoft ecosystem, especially for the next generation of enterprise applications.
Inside .Net Core
.Net Core is the new kid on the block, and because it’s new, it’s not particularly well understood. Perhaps best considered a radical refactoring of .Net to support cross-platform development, .Net Core has quickly become the heart of much of the .Net Foundation’s open source work. That’s an important feature, one that lets .Net Core respond more quickly to demand for new platforms than other .Net runtimes and libraries can. For example, Samsung is adding it to its Tizen OS, and a recent .Net Core release brought on support for code running on the Raspberry Pi. It’s also the foundation of Universal Windows Platform (UWP) applications built using the .Net languages.
Although .Net Core has many features found on the rest of the .Net platform, it’s focused on delivering console-based server applications. It offers developers tools to build and run command-line applications on Windows, MacOS, and Linux, but it’s also what you use to build ASP.Net Core web applications. Running on Windows Server Nano, .Net Core works with familiar tools to build and run microservices in Windows containers.
Because .Net Core lacks some commonly used .Net features, you’ll likely not use it to run existing workloads. It’s more a tool for building new applications intended to run as part of cloud workloads, or as part of a microservice refactoring of your enterprise monoliths. Recent updates have added support for UWP and for Xamarin Forms, so you can build GUI applications on small devices. This approach will form the basis for Tizen’s .Net support, using .Net Core on mobile Linux devices with Xamarin Forms for the UI.
Because .Net Core is lightweight and fast, it enjoys significant advantages over the more complex .Net Framework. However, because it doesn’t support many familiar libraries and extensions, there’s a learning curve compared to existing .Net development. But that doesn’t mean you must learn .Net from scratch to use .Net Core; you can bring your existing C# and F# language skills to .Net Core development.
What’s this .Net Standard then?
While .Net Core comes with CoreFX, a set of libraries you can install via NuGet as you need them (keeping your code small), .Net Core gains more commonality with the .Net Framework and with Mono if you use it with the .Net Standard libraries. Although these libraries are often referred to as .Net Standard, don’t be confused by the shorthand: This isn’t another runtime.
Confusingly, .Net Standard covers not only the libraries but is the name (actually, “netstandard”) used for a build target in .Net development, for letting you quickly define the libraries you need in your code and having them automatically handled by your IDE and compiler.
As part of the development of .Net, Microsoft standardized the runtime APIs through ECMA, the group responsible for the JavaScript standard. That standardization makes it possible for the same code to target different .Net runtimes, but the ECMA standard doesn’t go far enough. It failed to standardize the base class libraries needed to build more complex applications.
That’s where the .Net Standard library comes in, specifying the APIs that work across all the various .Net implementations, from Windows Phone’s Silverlight to applications running on Azure’s serverless PaaS, from Android and iOS Xamarin code to UWP on HoloLens.
One important point is that different .Net runtimes support different levels of the .Net Standard APIs, so code isn’t as portable as you would like. If you’re building code that needs to run on different versions of .Net, you’ll have to target the lowest common version of the standard libraries. Because libraries are delivered via NuGet, that’s not a problem. You simply need to be careful that you’re targeting the right version of .Net Standard for your choice of devices; note that the lower (and more widely applicable) the version, the fewer the features.
Microsoft’s refactoring of .Net is finally starting to make sense. Once you get over the confusion between .Net Standard (the libraries) and netstandard (the target), decisions become quite simple:
- If you’re working on large-scale applications that use much of the .Net ecosystem of workflow and data connection tools, stick with the .Net Framework.
- If you’re targeting cloud and mobile—and thinking of cross-platform development—the combination of .Net Core and the .Net standard libraries is for you.