{"id":7097,"date":"2017-07-13T12:00:27","date_gmt":"2017-07-13T11:00:27","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/?p=7097"},"modified":"2017-07-13T08:18:18","modified_gmt":"2017-07-13T07:18:18","slug":"introduction-microsoft-net-core","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2017\/07\/introduction-microsoft-net-core.htm","title":{"rendered":"Introduction to Microsoft .NET Core"},"content":{"rendered":"

A few months ago, I was (along with about 70 other rMVPs<\/a>) privileged\u00a0to be on a Skype call with Scott Hanselman<\/a>\u00a0(@shanselman<\/a>) as he gave an overview into Microsoft .NET Core. Some of what was discussed was confidential but the general overview of how .NET Core fits with the full .NET Framework and with Mono\/Xamarin was a great education for a non-developer like me and it seems fine to reproduce it here for the benefit of others.<\/p>\n

This is part 1 of a 2-part series, looking <\/em>at .NET versions and the <\/em>Microsoft .NET Core SDK. Tomorrow’s post moves on to look at <\/em>Microsoft .NET Standard.<\/em><\/p>\n

.NET versions<\/h3>\n

The first thing to understand is that .NET versioning is a mess<\/a> [my words, not Scott’s]:<\/p>\n

On a Windows machine with Visual Studio installed, open a command prompt and type clrver -all<\/code>. Chances are you’ll see versions 2.0 and 4.0. cd C:\\Windows\\Microsoft.NET\\Framework<\/code> and on my Windows 10\/Office 2016 machine I can see versions 1.0.3705, 1.1.4322, 2.0.50727 and 4.0.30319.<\/p>\n

So where is .NET 3.0? Well, 3.0 and 3.5 were the Windows Presentation Framework (WPF) and Windows Communication Framework (WCF), running on v2.0 of the Common Language Runtime (CLR). They are actually part of Windows!<\/p>\n

All of this makes developing for the .NET framework tricky. Side by side running for .NET 4.x is at the CLR level – if your app is developed for 4.6 and others are for 4.0, you may have a hard time convincing IT operations people to update and chances are you’ll need to drop down to 4.0.<\/p>\n

That (together with cross-platform capabilities) is where .NET Core comes in.<\/p>\n

Creating simple applications with the .NET Core SDK<\/h3>\n

.NET Core is in C:\\Program Files\\DotNet and is implemented as a driver (dotnet.dll). With a few simple commands we can create and run a console application:<\/p>\n

dotnet new console<\/code><\/p>\n

dotnet restore<\/code><\/p>\n

dotnet run<\/code><\/p>\n

That’s three steps to Hello World!<\/p>\n

It’s just as simple for a web application:<\/p>\n

dotnet new web<\/code><\/p>\n

dotnet restore<\/code><\/p>\n

dotnet run<\/code><\/p>\n

Then browse to http:\/\/localhost:5000.<\/p>\n

One difference in the web app is the presence of the<\/p>\n

<Project Sdk=\"Microsoft.NET.Sdk.Web\"><\/code><\/p>\n

line in the .csproj file. This signifies a “meta package” – a package of packages that avoids explicitly listing multiple package references (for cleaner code).<\/p>\n

Unlike in the (full) .NET Framework, we can specify the version of .NET Core to use in the .csproj file, meaning that multiple versions of the SDK can be used with whatever variety of libraries are needed:<\/p>\n

<TargetFramework>netcoreapp1.1<\/TargetFramework><\/code><\/p>\n

We can also add references to libraries with dotnet add reference libraryname<\/code>.\u00a0Adding a package with dotnet add package packagename<\/code> not only adds it but restores, downloads and checks compatibility. Meanwhile dotnet new solution<\/code> creates a solution file – something that would be complex to do manually.<\/p>\n

Why revert to a CLI?<\/h3>\n

So we’ve seen that you can be a successful .NET programmer without a visual editor. We can build an entire project system from the command line. .NET Core is not just about involving the Linux community with a cross-platform version of .NET but also about speed and Scott used an analogy of thinking of the CLI as creating a “2D” version to validate before working on the full “3D” GUI version.<\/p>\n

In the background (under the covers), the .NET Core SDK uses the NuGet package manager<\/a> (dotnet add package<\/code>), MSBuild (dotnet build<\/code>) and VSTest (dotnet new xunit<\/code> and dotnet test<\/code>).<\/p>\n

Visual Studio gives a better user interface but we can develop the basics very quickly using a command line and then get the best of both worlds – both CLI and GUI. What .NET Core does is lower the barrier to entry – getting up and running writing Microsoft.NET code in just a few minutes, for Windows, MacOS or Linux.<\/p>\n

Resources<\/h3>\n