Getting Started Guide

.NET Core is a general purpose development platform featuring automatic memory management and modern programming languages. It allows users to build high-quality applications efficiently. .NET Core is available in Red Hat Enterprise Linux and OpenShift Container Platform via certified containers.

.NET Core offers the following features:

The ability to follow a microservices-based approach, where some components are built with .NET and others with Java, but all can run on a common, supported platform in Red Hat Enterprise Linux and OpenShift Container Platform.

The capacity to more easily develop new .NET Core workloads on Microsoft Windows. Customers can deploy and run on either Red Hat Enterprise Linux or Windows Server.

A heterogeneous data center, where the underlying infrastructure is capable of running .NET applications without having to rely solely on Windows Server.

1.2. Install .NET Core

Enable the rh-dotnet21 Software Collection environment so you can run dotnet commands in the bash shell

This procedure installs the .NET Core 2.1 runtime with the latest 2.1 SDK. When a newer SDK becomes available, it automatically installs as a package update.

$ scl enable rh-dotnet21 bash

This command does not persist; it creates a new shell, and the dotnet command is only available within that shell. If you log out, use another shell, or open up a new terminal, the dotnet command is no longer enabled.

Warning

Red Hat does not recommend permanently enabling rh-dotnet21 because it may affect other programs. For example, rh-dotnet21 includes a version of libcurl that differs from the base RHEL version. This may lead to issues in programs that do not expect a different version of libcurl. If you want to enable rh-dotnet permanently, add the following line to your ~/.bashrc file.

1.4. Publish Applications

The .NET Core 2.1 applications can be published to use a shared system-wide version of .NET Core or to include .NET Core. These two deployment types are called framework-dependent deployment (FDD) and self-contained deployment (SCD), respectively.

For RHEL, we recommend publishing by FDD. This method ensures the application is using an up-to-date version of .NET Core, built by Red Hat, that includes a specific set of native dependencies. These native libraries are part of the rh-dotnet21 Software Collection. On the other hand, SCD uses a runtime built by Microsoft. Running applications outside the rh-dotnet21 Software Collection may cause issues due to the unavailability of native libraries.

1.4.1. Publish .NET Core Applications

Use the following command to publish a framework-dependent application.

$ dotnet publish -f netcoreapp2.1 -c Release

Optional: If the application is only for RHEL, trim out the dependencies needed for other platforms with these commands.

1.4.2. Publish ASP.NET Core Applications

When using the Microsoft SDK, ASP.NET Core 2.1 web applications are published with a dependency on the ASP.NET Core shared framework. This is a set of packages that are expected to be available on the runtime system.

When publishing on RHEL, these packages are included with the application. To include the packages using the Microsoft SDK, the MicrosoftNETPlatformLibrary property must be set to Microsoft.NETCore.App in the project file as shown below.

If you get an error containing the message unable to retrieve auth token: invalid username/password, you need to provide credentials for the registry.redhat.io server. Use the command $ podman login registry.redhat.io to log in. Your credentials are typically the same as those used for the Red Hat Customer Portal.

2.1. Installing Image Streams

The .NET Core image streams definition can be defined globally in the openshift namespace or locally in your specific project.

If you are a system administrator or otherwise have sufficient permissions, change to the openshift project. Using the openshift project allows you to globally update the image stream definitions.

$ oc project openshift

If you do not have permissions to use the openshift project, you can still update your project definitions starting with Step 2.

Run the following commands to list all available .NET Core image versions.

$ oc describe is dotnet -n openshift
$ oc describe is dotnet

The output shows installed images or the message Error from server (NotFound) if no images are installed.

To pull the images, OpenShift needs credentials for authenticating with the registry.redhat.io server. These credentials are stored in a secret.

Note

For OpenShift 3.11 and later, a secret is preconfigured for the openshift namespace.

Enter the following command to list secrets. The first column shows the secret name.

$ oc get secret | grep kubernetes.io/dockerc

To check the contents of a secret, you can decode the .dockercfg or .dockerconfigjson data from Base64 format. This allows you to see if you already have credentials for the registry.redhat.io server. Enter the following command to show the .dockercfg section in a secret.

You need to add a secret if there is no secret listed with credentials for the registry.redhat.io server.

Red Hat account credentials are used for registry.redhat.io access. If you are a customer with entitlements to Red Hat products, you already have account credentials to use. These are typically the same credentials used to log in to the Red Hat Customer Portal. To verify your Red Hat credentials, enter the following command and attempt to log in.

$ podman login registry.redhat.io

If you cannot log in, you first need to get an account with Red Hat. See Red Hat Container Registry Authentication for additional information. If you can log in, enter the following commands to create the secret.

Example: The following example shows a Jenkins pipeline added to OpenShift Container Platform. Note that when a Jenkins pipeline is added and no Jenkins master is running, OpenShift automatically deploys a master. See OpenShift Container Platform and Jenkins for additional information about deploying and configuring a Jenkins server instance.

In the example steps, the BuildConfig yaml file includes a simple Jenkins pipeline configured using the dotnet-21 Jenkins slave. There are three stages in the example BuildConfig yaml file:

Click Start Pipeline. It may take a while for the build to start because the Jenkins image(s) need to be downloaded first.

During the build you can watch the different pipeline stages complete in the OpenShift console. You can also click View Log to see the pipeline stages complete in Jenkins.

When the Jenkins pipeline build completes, go to Builds > Images. The dotnetapp image is built and available.

2.5. Environment Variables

The .NET Core images support a number of environment variables to control the build behavior of your .NET Core application. These variables can be set as part of the build configuration, or they can be added to an .s2i/environment file in the application source code repository.

Variable Name

Description

Default

DOTNET_STARTUP_PROJECT

Selects project to run. This must be a project file (for example, csproj or fsproj) or a folder containing a single project file.

.

DOTNET_SDK_VERSION

Selects the default sdk version when building. If there is a global.json file in the source repository, that takes precedence. When set to latest the latest sdk in the image is used.

Lowest sdk version available in the image.

DOTNET_ASSEMBLY_NAME

Selects the assembly to run. This must not include the .dll extension. Set this to the output assembly name specified in csproj (PropertyGroup/AssemblyName).

The name of the csproj file

DOTNET_RESTORE_SOURCES

Specifies the space-separated list of NuGet package sources used during the restore operation. This overrides all of the sources specified in the NuGet.config file.

DOTNET_TOOLS

Specifies a list of .NET tools to install before building the app. It is possible to install a specific version by post pending the package name with @<version>.

DOTNET_NPM_TOOLS

Specifies a list of NPM packages to install before building the application.

DOTNET_TEST_PROJECTS

Specifies the list of test projects to test. This must be project files or folders containing a single project file. dotnet test is invoked for each item.

DOTNET_CONFIGURATION

Runs the application in Debug or Release mode. This value should be either Release or Debug.

Release

DOTNET_VERBOSITY

Specifies the verbosity of the dotnet build commands. When set, the environment variables are printed at the start of the build. This variable can be set to one of the msbuild verbosity values (q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]).

HTTP_PROXY, HTTPS_PROXY

Configures the HTTP/HTTPS proxy used when building and running the application.

DOTNET_RM_SRC

When set to true, the source code will not be included in the image.

DOTNET_SSL_DIRS

Used to specify a list of folders/files with additional SSL certificates to trust. The certificates are trusted by each process that runs during the build and all processes that run in the image after the build (including the application that was built). The items can be absolute paths (starting with /) or paths in the source repository (for example, certificates).

NPM_MIRROR

Uses a custom NPM registry mirror to download packages during the build process.

ASPNETCORE_URLS

This variable is set to http://*:8080 to configure ASP.NET Core to use the port exposed by the image. Changing this is not recommended.

2.6. Sample Applications

Three sample applications are available:

dotnet-example: This is the default model–view–controller (MVC) application.

dotnet-runtime-example: This shows how to build an MVC application using a chained build. The application is built in dotnet/dotnet-21-rhel7. The result is deployed in dotnet/dotnet-21-runtime-rhel7. Note that chained builds are not supported on OpenShift Online.

dotnet-pgsql-persistent: This is the Microsoft ASP.NET Core MusicStore sample application using a PostgreSQL backend.

To add the samples using the OpenShift Web Console, browse to your project and click Add to project. You can filter for dotnet. If the samples do not show up, you can add them to your installation by running the following commands.

Chapter 3. Migrating to .NET Core 2.1

This chapter provides migration information for .NET Core 2.1.

3.1. Migrating from previous versions of .NET Core

Microsoft provides instructions for migrating from most previous versions of .NET Core. When migrating, the following ASP.NET Core 2.0 property should no longer be specified. It should remain the default value for .NET Core 2.1. Make sure to remove this property from the project file and command line, if it is being specified there.

If migrating from .NET Core 1.x to 2.0, see the first few related sections in Migrate from ASP.NET Core 1.x to 2.0. These sections provide guidance that is appropriate for a .NET Core 1.x to 2.0 migration path.

3.2. Migrating from .NET Framework to .NET Core 2.1

Review the following information to migrate from the .NET Framework.

3.2.1. Migration considerations

Several technologies and APIs present in the .NET Framework are not available in .NET Core. If your application or library requires these APIs, consider finding alternatives or continue using the .NET Framework. .NET Core does not support the following technologies and APIs.

Additionally, a number of .NET APIs can only be used in Microsoft Windows environments. The following list shows a few examples of these Windows-specific APIs.

Microsoft.Win32.Registry

System.AppDomains

System.Drawing

System.Security.Principal.Windows

Consider using the .NET Portability Analyzer to identify API gaps and potential replacements. For example, enter the following command to find out how much of the API used by your .NET Framework 4.6 application is supported by .NET Core 2.1.

Several APIs that are not supported in the out-of-the-box version of .NET Core may be available from the Microsoft.Windows.Compatibility nuget package. Be careful when using this nuget package. Some of the APIs provided (such as Microsoft.Win32.Registry) only work on Windows, making your application incompatible with Red Hat Enterprise Linux.

3.2.2. .NET Framework migration articles

Refer to the following Microsoft articles when migrating from .NET Framework.

Legal Notice

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.