Hands-On Mobile Development with .NET Core

Chapter 1. Getting Started with .NET Core

.NET Core (previously known as .NET vNext) is the general umbrella term used for Microsoft's cross-platform toolset that aims to solve the shortcomings of centralized/machine-wide frameworks (NET framework) by creating a portable, platform agnostic, modular runtime and framework. This decentralized and modular development platform allows developers to create applications for multiple platforms using the common .NET base class libraries (NET standard), as well as various runtimes and application models, depending on the target platforms. This chapter will give you a brief introduction to .NET Core while explaining different tiers of .NET Core infrastructure. Languages and runtimes, as well as extensions that can be used together with .NET Core will be discussed and analyzed.

The combination of.NET Core, .NET Standard, and Xamarin is the key to cross platform projects, and opens many doors that were previously for Windows-only developers. Creating web applications that can run on Linux machines and containers, and the implementation of mobile applications that target iOS, Android, Universal Windows Platform (UWP), and Tizen are just a couple of examples to emphasize the capabilities of this cross-platform approach.

In this chapter, the following sections will guide you through getting started with .NET Core:

Cross-platform development
Introduction to .NET Core
.NET foundation
Developing with .NET Core

Cross-platform development

The term cross-platform application development refers to the process of creating a software application that can run on multiple operating systems. In this book, we will not try to answer the question of why, but how – more specifically, will try to create a cross-platform application using the toolset provided by Microsoft and .NET Core.

Before we start talking about .NET Core, let's take a look at the process of developing an application for multiple platforms. Faced with the cross-platform requirement, the product team can choose multiple paths that will lead the developers through different application life cycles.

Throughout this book, we will have hypothetical user stories defined for various scenarios. We will start with an overall user story that underlines the importance of .NET Core:

"I, as a product owner, would like to have the client ShopAcross application running on iOS, Android mobile platforms, as well as Windows, Linux, and macOS desktop runtimes, so that I can increase my reach and user base."

In order to meet these demands, we can choose to implement the application in several differentways:

Fully native applications
Hybrid applications
Cross platform

Developing fully native applications

Following this path would create probably the most performant application, with increased accessibility to the platform APIs for the developers. However, the development team for this type of development would require specific know-how and skill sets so that the same application can be created on multiple platforms, also increasing the developer hours that need to be invested in the application.

Considering the platform set we mentioned previously, we would potentially need to develop the client application in Cocoa and CocoaTouch (macOS and iOS), Java (Android), .NET (Windows), or C++ (Linux), and finally build a web service infrastructure in another language of our choice. In other words, this approach is, in fact, implementing a multi-platform application rather than a cross-platform one.

Hybrid applications

Native hosted web applications (also known as hybrid applications) are another popular choice for (especially mobile) developers. In this architecture, a responsive web application would be hosted on a thin native harness on the target platform. The native web container would also be responsible for providing access to the web runtime on native platform APIs. These hybrid applications wouldn't even need to be packaged as application packages, but as Progressive Web Apps (PWAs) so that users can access them right from their web browsers. While the development resources are even more efficiently used than the native cross-platform framework approach, this type of application is generally prone to performance issues.

In reference to the business requirements at hand, we would probably develop a web service layer and a small Single Page Application (SPA), part of which is packaged as a hybrid application. The other parts can be hosted as a web application.

Native cross-platform frameworks

Development platforms such as React Native, Xamarin, and .NET Core provide the much-required abstraction for the target platforms, so that development can be done using one framework and development language for multiple runtimes. In other words, the developers are still using the APIs provided by the native platform (for example, Android or iOS SDK), but the development is executed in a single language and framework. This approach not only decreases the development resources, but also saves you from the burden of managing multiple source repositories for multipleplatforms. This way, the same source is used to create multiple application heads.

For instance, using .NET Core, the development team can implement all target platforms using the same development suite and language, thus creating multiple client applications for each target platform, as well as the web service infrastructure.

In a cross-platform implementation, architecturally speaking, the application is made up of three distinct tiers:

Application model (implementation layer for the consumer application)
Framework (the toolset available for developers)
Platform abstraction (the harness or runtime to host the application)

In this context, we, in essence, are in pursuit of creating a platform-agnostic application layer that will be catered for on a platform abstraction layer. The platform abstraction layer, whether it's on the native web host or the native cross-platform framework, is responsible for providing the bridge between the single application implementation and the polymorphic runtime component.

.NET Core and Mono provide the runtime, while the .NET Standard provides the framework abstraction, which means that cross-platform applications can be implemented and distributed on multiple platforms. Using Xamarin with the .NET Standard framework on mobile applications and .NET Core on the web infrastructure, sophisticated cloud-supported native mobile applications can be created.

Introduction to .NET Core

In order to understand the roots of and motivation for let us start with a quote:

"Software producers who maximize their product's potential for useful combination with other software, while at the same time minimizing any restrictions upon its further re-combination, will be the survivors within a software industry that is in the process of reorganizing itself around the network exchange of commodity data."

-- David Stutz – General Program Manager for Shared Source Common Language Infrastructure, Microsoft, 2004.

.NET Core dates back as early as 2001 when Shared Source Common Language Infrastructure (SSCLI) was shared sourced (not for commercial use) under the code name Rotor. This was the ECMA 335, that is, the Common Language Infrastructure (CLI) standard implementation. Rotor could be built on FreeBSD (version 4.7 or newer) and macOS X 10.2. It was designed in such a way that a thin Platform Abstraction Layer (PAL) was the only thing that was needed to port the CLI to a different platform. This release constitutes the initial steps to migrate .NET to a cross-platform infrastructure.

2001 was also the year the Mono project was born as an open source project that ports parts of .NET to the Linux platform as a development platform infrastructure. In 2004, the initial version of Mono was released for Linux, which would lead to ports on other platforms such as iOS (MonoTouch) and Android (MonoDroid), and would eventually be merged into the .NET ecosystem under the Xamarin name.

One of the driving factors for this approach was the fact that the .NET framework was designed and distributed as a system-wide monolithic framework. Applications that are dependent on only a small portion of the framework required the complete framework to be installed on the target operating system. It did not support application-only scenarios where different applications can be run on different versions without having to install a system-wide upgrade. However, more importantly, applications that were developed with .NET were implicitly bound to Windows because of the tight coupling between the .NET framework and Windows API components. .NET Core was born out of these incentives and opened up the doors of various platforms for .NET developers.

Semantically speaking, .NET Core describes the complete infrastructure for the whole set of cross-development tools that rely on a common language infrastructure and multiple runtimes, including .NET Core runtime, .NET, also known as Big CLR, Mono runtime, and Xamarin:

Adapted from: Soumyasch [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0/)]

In this setup, the .NET Core CLI is made up of the base class library implementation, which defines the standards that need to be provided by the supported runtimes. The base class library is responsible for providing the PAL, which is provided by the hosting runtime under the name of the Adaption Layer. This infrastructure is supported by compiler services such as Roslyn and Mono Compiler (MCS ), as well as Just-In-Time (JIT) and Ahead-of-Time (AOT) compilers such RyuJIT (.NET Core), mTouch, and LLVM (for Xamarin.iOS) in order to produce and execute the application binaries for the target platform.

Overall, .NET Core is a rapidly growing ecosystem with various dynamic frameworks, runtimes, and tools. Most of these components can be found on GitHub as open source projects under the supervision of the .NET Foundation.

.NET Foundation

The .NET Foundation is an independent organization that supports open source development and collaboration within the .NET ecosystem. The .NET foundation supports the development of active projects within the ecosystem by evangelizing the technologies through organizing/sponsoring meetups and by active involvement in community-driven projects.

The .NET Foundation portfolio grew especially large due to the projects that were brought in by the acquisition of Xamarin.

Notable .NET Foundation projects

Some of the most notable projects that are generally used in modern .NET applications, as well as cross-platform mobile applications, are as follows:

.NET Core
ASP.NET Core
Roslyn
Reactive Extensions
Entity Framework
Identity Server
ML.NET
Xamarin and Xamarin.Forms
xUnit.NET

.NET Core

The .NET Core project is composed of the .NET framework implementation and the common language runtime for .NET Core (CoreFX and CoreCLR ). Additionally .NET Core tools such as the .NET Core command-line interface can also be found as separate repositories. The community is free to make contributions, as well as submit issue reports.

ASP.NET Core

ASP.NET Core is the cross-platform implementation of ASP.NET. As a platform agnostic web development framework, applications created with it can be hosted on multiple platforms, as well as on Windows using classic .NET. ASP.NET MVC, Web API, web pages, and SignalR are some of the repositories under the ASP.NET Core project.

Roslyn

Complete implementation of Roslyn (.NET compiler platform for C# and Visual Basic) can be found on GitHub as part of the .NET Foundation group. Roslyn is the implementation of the compiler as a service paradigm and has various extensibility points, including customizable code analyzers.

Reactive Extensions for .NET

Reactive Extensions for .NET is a library that provides developers with event-based asynchronous observable sequences and LINQ style query operators. Extensions can be used in .NET applications using the system's reactive namespaces and its children.

Entity Framework

The Entity Framework is the recommended data access technology for modern .NET applications. The newest version of the Entity Framework was built from scratch using .NET, Core so that it can be used in cross-platform applications, from ASP.NET Core applications to device-specific scenarios such Xamarin and UWP.

IdentityServer

OpenID Connect and the OAuth 2.0 Framework for Katana and ASP.NET Core are the components of identity server project. They provides tools that developers can use to enable authentication as a service, Single Sign-on (SSO), and federation gateways in their applications.

ML.NET

This project allows developers to include cognitive functions and AI-related implementations in their applications with .NET. The same open-source is used by the Hello feature on Windows 10. Developers can use this framework to integrate custom machine learning features into their applications without any prior knowledge about neural networks, artificial intelligence, or machine learning. This library also allows integration with other machine learning libraries such as TensorFlow, ONNX, and Infer.NET.

Xamarin and Xamarin.Forms

Miguel de Icaza, part of the board of directors of the .NET Foundation, publicly announced that Xamarin, Xamarin.SDK, and Xamarin.Forms, as well as the Mono runtime ports for iOS and Android, are to be part of the .NET foundation and open sourced in Evolve 2016. Even though these projects are not listed on the Foundation site, they can be found on GitHub under the common MIT license.

xUnit.net

This is a free, open source, community-based unit testing tool for the .NET Framework. This testing framework is used in many of the aforementioned repositories and projects as the main testing tool. It has strong integration with newer versions of Visual Studio and Team Foundation Server.

Developing with .NET Core

.NET Core applications can be developed with Visual Studio on the Windows platform and Visual Studio for Mac (inheriting from Xamarin Studio) on macOS. Visual Studio Code (an open source project) and Rider (JetBrain's development IDE) provide support for both of these platforms, as well as Unix-based systems. While these platforms provide the desired user-friendly development UI, technically, .NET core applications can be written with a simple text editor and compiled using the .NET Core command-line toolset:

As we mentioned previously, the only intrinsic runtime in the .NET Core CLI is the .NET Core runtime, which is primarily used for creating console applications with access to the complete base class library.

Without further ado, let's create our first cross-platform application with the CLI tools and see how it behaves on multiple target platforms.

Creating a runtime agnostic application

To begin with, we will create our console application on macOS that has .NET Core installed:

$ mkdir demo && cd $_
$ dotnet --version
2.1.301
$ dotnet new console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on /demo/demo.csproj...
 Restoring packages for /demo/demo.csproj...
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.props.
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.targets.
 Restore completed in 236.91 ms for /demo/demo.csproj.

Restore succeeded.

Note

In this example, we have used the console template, but there are many other templates available out of the box, such as class library, unit test project, asp.net core, as well as more specific templates, such as razor page or MVC ViewStart.

Now, the helloworld console application should have been created in the folder that you specified in the first step.

In order to restore the NuGet packages associated with any project, you can use the dotnet restore command in a command line or Terminal window, depending on your operating system.

Note

Generally, you don't need to use the restore command, as the compilation already does this for you. In the case of template creation, the last step actually restores the NuGet packages.

Now that our application project is ready (after editing the program.cs file), we can build and run the console application:

Here, we used the run command to compile and run our application in the current platform (macOS). If you were to navigate to the build folder, you would notice that, instead of an executable, the CLI actually created a Dynamic Link Library (DLL) file. The reason for this is that, since no other compilation option was defined, the application was created as a framework-dependent application. We can try running the application with the dotnet command, which is called the driver:

$ cd bin/Debug/netcoreapp2.1/
$ ls
demo.deps.json demo.pdb demo.runtimeconfig.json 
demo.dll demo.runtimeconfig.dev.json 
$ dotnet demo.dll
Hello .NET Core

Here, it is important to note that we used the description framework-dependent (in this case, the NETCore.App 2.1 runtime). If we were discussing the .NET framework prior to .NET Core, this would strictly refer to the Windows platform. In this context, however, it refers to an application that is only dependent on the framework itself while being platform-agnostic. In order to test our application on Windows, we can copy the bin folder to a Windows machine with the target framework installed and try running our application:

Note

In order to verify that the required framework is installed on the target machine, you can use the dotnet --info or dotnet --list-sdks commands, which will list the installed runtimes on the target machine.

In order to test the runtime independence of the created demo.dll file, we can try running it with the mono runtime. On macOS, you can try the following command to execute our application:

$ cd bin/Debug/netcoreapp2.1/
$ mono demo.dll
Hello .NET Core

Defining a runtime and self-contained deployment

In the previous example, we created a console application that is operating system-agnostic. However, it had a dependency on the NETCore.App runtime. What if we want to deploy this application to a target system that doesn't have .NET Core runtime and/or SDK installed?

When the .NET Core applications need to be published, you can include the dependencies from the .NET Core framework and create a so-called self-contained package. However, by going down this path, you would need to define the target platform (operating system and CPU architecture) using a Runtime Identifier (RID) so that the .NET CLI can download the required dependencies and include them in your package.

The runtime can be defined either as part of the project file or as a parameter during publish execution:

Here, we have edited the project file to target Windows 10 with the x64 architecture. Now, if we were to publish the application (note that the publishing process is going to take place on macOS), it would create an executable for the defined target platform:

$ nano demo.csproj
$ dotnet publish
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Restoring packages for /demo/demo.csproj...
 Installing runtime.win-x64.Microsoft.NETCore.DotNetAppHost 2.1.1.
 Installing runtime.win-x64.Microsoft.NETCore.DotNetHostResolver 2.1.1.
 Installing runtime.win-x64.Microsoft.NETCore.DotNetHostPolicy 2.1.1.
 Installing runtime.win-x64.Microsoft.NETCore.App 2.1.1.
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.props.
 Generating MSBuild file /demo/obj/demo.csproj.nuget.g.targets.
 Restore completed in 18.81 sec for /demo/demo.csproj.
 demo -> /demo/bin/Debug/netcoreapp2.1/win10-x64/demo.dll
 demo -> /demo/bin/Debug/netcoreapp2.1/win10-x64/publish/

The publish folder, in this case, would include all the necessary packages from the .NET Core runtime and framework targeting the Windows 10 runtime:

Notice that, once the deployment target platform is defined, an executable file is created and there is no more need for the driver. In fact, the executable's sole purpose here is to act as the access point (host) to the dynamic class library that is created by .NET Core.

Some of the most notable runtimes include Windows 7 to Windows 10 on three different architectures (x86, x64, and arm), multiple macOS versions, and various distributions and versions of Linux, including OpenSuse, Fedora, Debian, Ubuntu, RedHat, Tizen, and so on.

Defining a framework

In the previous examples, we have been using netcoreapp2.1 as the target framework. While, for the self-contained deployment for this console application, this proves to be sufficient, if we were preparing a Xamarin application or a UWP. Net Standard, we would have been better off using target platform frameworks such as Xamarin.iOS.

The target platform framework can be changed using the <TargetFrameworks> project property. We would have to use the moniker assigned to the desired framework: