Page 22 - MSDN Magazine, September 2017

Figure 4 The Project Structure You Created
In such an environment, code sharing becomes a major chal- lenge. You need to understand where APIs are available and make sure that shared components only use APIs that are available across all .NET implementations you’re using.
And that’s where .NET Standard comes in. .NET Standard is a specification. Each .NET Standard version defines the set of APIs that all .NET implementations must provide to conform to that version. You can think of it as yet-another .NET stack, except that you can’t build apps for it, only libraries. It’s the .NET implementation you should use for libraries that you want to reference from everywhere.
You’re probably wondering which APIs .NET Standard covers. If you’re familiar with .NET Framework, then you should be famil- iar with the BCL, which I mentioned earlier. The BCL is the set of fundamental APIs that are independent of UI frameworks and application models. It includes the primitive types, file I/O, networking, reflection, serialization, XML and more.
All .NET stacks implement some version of .NET Standard. The rule of thumb is that when a new version of a .NET implemen- tation is produced, it will usually implement the latest available version of the .NET Standard.
A good analogy is HTML and browsers: Think of the HTML spec- ification as the .NET Standard and the different browsers as the .NET implementations, such as .NET Framework, .NET Core and Xamarin.
At this point, you’re probably curious how you can use .NET Standard. In fact, you already have. Remember when we created the logic class library earlier? Let’s take a closer look at the project file:
$ cd logic
$ cat logic.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>
Let’s contrast this with the “hello” console application project file:
$ cd ..\\hello
$ cat hello.csproj
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<ProjectReference Include="..\\logic\\logic.csproj" />
</ItemGroup>
<PropertyGroup>
<OutputType>Exe</OutputType> <TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup> </Project>
$ tree /f │ ├───hello
│ hello.csproj
│ Program.cs │
├───logic
│ HelloWorld.cs
│ logic.csproj │
├───tests
│ tests.csproj
│ UnitTest1.cs │
└───web
Program.cs Startup.cs web.csproj
app.Run(async (context) => {
var name = Environment.UserName;
var message = logic.HelloWorld.GetMessage(name); await context.Response.WriteAsync(message);
});
To start the development Web server, just use dotnet run again:
$ dotnet run
Hosting environment: Production
Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down.
Browse to the displayed URL, which should be http://localhost:5000. At this point, your project structure should look like Figure 4. To make it easier to edit the files using Visual Studio, let’s also
create a solution file and add all the projects to the solution:
$ cd ..
$ dotnet new sln -n HelloWorld
$ ls -fi *.csproj -rec | % { dotnet sln add $_.FullName }
As you can see, the .NET Core CLI is powerful and results in a lean experience that developers from other backgrounds should find quite familiar. And while you used dotnet with PowerShell on Windows, the experience would look quite similar if you were on Linux or macOS.
Another huge benefit of .NET Core is that it supports self- contained deployments. You could containerize your application using Docker in such a way that it has its own copy of the .NET Core runtime. This lets you run different applications on the same machine using different .NET Core versions without them inter- fering with each other. Because .NET Core is open source, you can also include nightly builds or even versions you’ve modified or built yourself, potentially including modifications you made. However, that’s beyond the scope of this article.
Introduction to .NET Standard
When you’re building modern experiences, your app often spans multiple form factors and, therefore, multi- ple .NET implementations. In this day and age, custom- ers pretty much expect that they can use your Web app from their mobile phone and that data can be shared via a cloud-based back end. When using a laptop, they also want to get access via a Web site. And for your own infrastructure, you likely want to use command- line tools and potentially even desktop apps for letting your staff manage the system. See Figure 5 for how the different .NET implementations play into this.
Figure 5 Descriptions of .NET Implementations
OS
Open Source
Purpose
.NET Framework
Windows
No
Used for building Windows desktop applications and ASP.NET Web apps running on IIS.
.NET Core
Windows, Linux, macOS
Yes
Used for building cross-platform console apps and ASP.NET Core Web apps and cloud services.
Xamarin
iOS, Android, macOS
Yes
Used for building mobile applications for iOS and Android, as well as desktop apps for macOS.
.NET Standard
N/A
Yes
Used for building libraries that can be referenced from all .NET implementations, such as .NET Framework, .NET Core and Xamarin.
18 msdn magazine
.NET Standard