First, A Little History on .NET for software development
During the late 90s, Microsoft started work on something that they were calling Next Generation Windows Services (or NGWS for short). NGWS was originally designed to let Windows users access all kinds of services over the Internet.
In fact, in an early presentation for NGWS, Steve Balmer (who hated the name NGWS) said that it would allow users to access services like Spell Checkers or secure places to store Credit Card information.
Hmm... That sounds oddly similar to modern webservices.
The major difference between NGWS and what became .NET is that applications created with NGWS would communicate with each other almost exclusively using XML - which was also a very new thing at the time. Choosing XML as the communication medium was an early attempt at create a cross platform experience: NWGS applications would be able to communicate with any other application which could accept and understand XML.
Eventually XML took a place on the back burner and a new name was chosen - .NET. According to this Stack Overflow answer (by Justin Grant, who was an engineer on what became .NET), there are quite a few subtle reasons why ".NET" was chosen over NGWS:
- mirrored the domain suffix of (at the time) every ISP, so was intended to remind users that "web-enabling your software" was the core scenario being targetted by this work
- was more approachable to business types and CIOs than geekier names like "Universal Runtime" or "COM+ 2.0"
- had practical benefits like: being short, easy to spell, globalized well, could leverage already-owned domain names for every Microsoft product, etc.
- actually passed legal/trademark review (surprisingly difficult!)
In 2002, Microsoft released Visual Studio.NET along with .NET Framework version 1. Version 1 had a lot of features and was a pretty big divergence from the other frameworks that Microsoft supported at the time. Some of the features included:
- Common Language Infrastructure - this allowed developers to write an application in C# (I'll get to that in a moment), VB.NET or J# (or any combination) and have them all compile to the same binary.
- Common Language Runtime
- Standard Class libraries for Windows features
- Memory Management
With .NET version 1 and Visual Studio.NET came C# which according to a blog post by James Kovack (another engineer at Microsoft at the time):
The codename of C# was Project Cool, which was rumoured to be a clean-room implementation of Java. This was back in the days when Sun was suing Microsoft over bastardizing the Java language.
C# name was musically inspired. It is a C-style language that is a step above C/C++, where sharp (#) means a semi-tone above the note. (Being a musician myself, I think this is awfully fun.) Back when .NET made its debut, an amusing quip from the Linux crowd was to refer to C# as Db (D-flat), which is the same note as C#, but has different connotations. Two MS Research languages also bear musically-related names: Polyphonic C# and F#.
C# had been in development since around the year 2000, and it's development was lead by Anders Hejisberg. C# was developed at the same time as .NET's Common Language Runtime, so design decisions for C# affected the design of the CLR and vice versa.
So what is .NET Core and what impact does it have on software development?
Ever since Satya Nadella took over as CEO at Microsoft, there has been a refocus towards open source and cross platform software. For instance, Azure now has the ability to run Linux VMs (rather than just Windows ones), SQL Server is coming to Linux, and the next iteration of .NET has been re-branded as .NET Core.
So .NET Core is (at the time of writing) a slimmed down version of the .NET framework. You can read about the design decisions and reasons why (for version 1.0 at the very least) only a subset of the .NET framework features are implemented here.
Not only is .NET Core a cross platform implementation of the .NET Framework it's also completely open source and hosted, in it's entirety on GitHub. This is a very big first for Microsoft, as it means that anyone can contribute to the code or produce a build for an unsupported system.
It also means that if you don't run a Windows system, or just don't want to run .NET Framework, then you can install .NET Core and build applications and websites with it today.
What Can I Do With .NET Core That I Can't With the .NET Framework?
You can still build all of the application types that you could with the .NET framework (Console Applications, ASP.NET websites, Services, etc.). But there are a few caveats to consider. Here is Microsoft's description of .NET Core from their GitHub repository:
.NET Core and the .NET Framework have (for the most part) a subset-superset relationship. .NET Core is named "Core" since it contains the core features from the .NET Framework, for both the runtime and framework libraries. For example, .NET Core and the .NET Framework share the GC, the JIT and types such as String and List.
.NET Core was created so that .NET could be open source, cross platform and be used in more resource-constrained environments.
And a list of the supported architectures and formats can be found on the Roadmap for .NET Core.
It's important to read up on what features .NET Core supports before jumping directly into developing for it, so here are some helpful links and reference materials for .NET Core.
This is, by far, the best place to start. Scott Hanselman and Scott Hunter take you through how to throw together an ASP.NET Core application, using Visual Studio 2015, across a 7 hour course of videos. Each video has a set of multiple choice questions after it, but you don't need to answer these unless you want the course to count towards your MVA account.
Some of the information is a little out of date, and it focuses on Windows users (the hosts use Visual Studio 2015 exclusively) as the course was put together in the September of 2015, but a lot of the core information is still relevant.
Anyone who remembers using the MSDN library for documentation will remember how badly it was put together. To be fair, when it was first set up it was good. But we've gotten to a point where we expect a rich web experience, which is what the MSDN documentation library is not.
The .NET Core documentation is really well put together, and is rendered from all accepted pull requests at the GitHub page for it (which can be found here: https://github.com/aspnet/Docs/tree/master/aspnet).
Since .NET Core is open source and is being hosted on GitHub, anyone can go read the code. This will help to understand how something works, by reading why it works the way that it does.
Which goes hand in hand with "Atwood's Law"
Every few weeks, the .NET Core team leads at Microsoft have a "stand up" which takes the format of an informal Google Hangouts chat. During these hangouts blog posts are covered, interesting projects that have been built with .NET Core are dissected, and milestones are discussed.
This is extremely useful for anyone who wants to know what's coming up in the .NET Core timeline and learn about real life products which have been built using .NET Core.
Written and updated by the actual engineers who are working on .NET Core, this is an invaluable resource for anyone wanting to know about .NET Core. It covers everything even slightly related to .NET Core. Just take a look at the word cloud:
Word Cloud captured from the .NET Blog (captured on 04/10/2016)
Scott Hanselman helps to run live.asp.net and has the title of "Principal Program Manager - Outreach and Community - .NET, ASP.NET, and Open Source" at Microsoft. Which means that he is in the perfect position to announce updates to .NET Core.