Using .NET Core 2.0 and RHEL in Linux Containers

 

September 5, 2017
Don Schenck
Related topics:
.NET
Related products:
Red Hat Enterprise Linux

.NET Core 2.0 represents the maturation of the .NET Core development effort. This, the third release (previous releases being version 1.0 and 1.1), brings nearly 20,000 more APIs and a much richer and deeper developer experience. To put it in the vernacular, .NET Core is ready for prime time.

This blog post will show you the critical steps and configurations necessary to use .NET Core 2.0 running on RHEL inside your Linux containers.

The Challenge

Beginning with .NET Core 2.0, Microsoft is using meta-references to get the bits necessary for ASP.NET programs. Prior to version 2.0, you were required to list every individual library needed for your ASP.NET program to work. While the theory behind this idea seemed sound -- you'd only ask for the bits you really required -- in practice, there were some issues. For starters, you're basically going to want all the parts of ASP.NET. That's a broad statement, but more accurate than not.

Secondly, and more problematic, it was, shall we call it a "challenge", to keep the references up-to-date and properly versioned. If you are referencing 15 libraries in one project, it's by definition 15 times more work to keep them all updated versus one lone reference.

Consider the following .csproj file versus the generated file in the second example:

vs2ocp.csproj file using ASP.NET meta-package:

<Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>
<TargetFramework>netcoreapp2.0

TargetFramework>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>

<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
</ItemGroup>

<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<None Update="standalone.sh" Condition="'$(RuntimeIdentifier)' == 'rhel.7-x64' and '$(SelfContained)' == 'false'" CopyToPublishDirectory="PreserveNewest" />
</ItemGroup>
</Project>

Generated code:

<Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>
<TargetFramework Condition="'$()' == ''">netcoreapp2.0</TargetFramework>
<TargetFramework Condition="'$()' != ''"></TargetFramework>
<UserSecretsId Condition="'$(IndividualAuth)' == 'True' OR '$(OrganizationalAuth)' == 'True'">aspnet-vs2ocp-612A697F-5F13-4384-8F85-4B1214C705C6
<WebProject_DirectoryAccessLevelKey Condition="'$(OrganizationalAuth)' == 'True' AND '$(OrgReadAccess)' != 'True'">0
<WebProject_DirectoryAccessLevelKey Condition="'$(OrganizationalAuth)' == 'True' AND '$(OrgReadAccess)' == 'True'">1
</PropertyGroup>
<!--#if (IndividualLocalAuth && UseLocalDB) -->

<!--#endif -->
<ItemGroup Condition=" '$(IndividualLocalAuth)' == 'True' AND '$(UseLocalDB)' != 'True' ">
<None Update="app.db" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

<ItemGroup Condition="'$()' == ''">
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.0" PrivateAssets="All" Condition="'$(IndividualAuth)' == 'True'" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.0.0" PrivateAssets="All" Condition="'$(IndividualAuth)' == 'True'" />
</ItemGroup>
<ItemGroup Condition="'$()' != ''">
<PackageReference Include="Microsoft.AspNetCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.Cookies" Version="2.0.0" Condition="'$(IndividualAuth)' == 'True' OR '$(OrganizationalAuth)' == 'True'" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="2.0.0" Condition="'$(OrganizationalAuth)' == 'True' OR '$(IndividualB2CAuth)' == 'True'" />
<PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="2.0.0" Condition="'$(IndividualLocalAuth)' == 'True'" />
<PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="2.0.0" Condition="'$(IndividualLocalAuth)' == 'True'" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="2.0.0" PrivateAssets="All" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0" PrivateAssets="All" Condition="'$(IndividualLocalAuth)' == 'True'" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="2.0.0" Condition=" '$(IndividualLocalAuth)' == 'True' AND '$(UseLocalDB)' != 'True'" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" Condition=" '$(IndividualLocalAuth)' == 'True' AND '$(UseLocalDB)' == 'True'" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.0" PrivateAssets="All" Condition="'$(IndividualLocalAuth)' == 'True'" />
<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.0.0" Condition="'$(UseBrowserLink)' == 'True'" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.0.0" PrivateAssets="All" Condition="'$(IndividualAuth)' == 'True'" />
</ItemGroup>

<ItemGroup Condition="'$(NoTools)' != 'True'">
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.0" Condition="'$(IndividualLocalAuth)' == 'True'" />
<DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="2.0.0" Condition="'$(IndividualAuth)' == 'True' OR '$(OrganizationalAuth)' == 'True'" />
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>

</Project>

As you can see, the meta package does a lot of the heavy lifting.

To make things fast, this combination of libraries are rolled into the runtime store, a store of pre-compiled libraries. This makes installation and start-up much faster, as they are stored locally. They are assumed to be part of the .NET Core installation on the machine.

The Core of the Challenge

With .NET Core 2.0, one of the artifacts being shipped with .NET Core is the Runtime Package Store (which enables the creation of pre-compiled package cache, decreasing deployment size and start-up times). The goal of this artifact is to create smaller and faster deployments of ASP.NET applications.  However, it introduces an assumption: any ASP.NET application will assume that the Runtime Package Store is present with .NET Core. If the Runtime Package Store is missing, the application will fail at runtime.

(More background details about the package store and how it works and what benefits it brings is available here: https://github.com/dotnet/designs/issues/8 ).

For Red Hat, this introduces a problem. We currently do not build ASP.NET from source. As a result, the ASP.NET Runtime Package Store is not present in our .NET Core. Any ASP.NET application - no matter if they are built using our SDK or Microsoft's SDK - will, therefore, fail to run on top of our distribution of .NET Core.
 

Is There A Solution In Sight?

Yes. Red Hat and Microsoft are working very closely to streamline this situation. In the meantime...
 

What's A Developer To Do?

No worries; of course we have a solution. And, to be honest, it's No Big Deal. It involves a small script and adding one tiny section to your project (e.g. *.csproj) file.
 
For starters, add this section to your project file; in this example case, this is example.csproj:
 
<ItemGroup>
<None Update="standalone.sh" Condition="'$(RuntimeIdentifier)' == 'rhel.7-x64' and '$(SelfContained)' == 'false'" CopyToPublishDirectory="PreserveNewest" />
</ItemGroup>
 
Notice the reference to the script file "standalone.sh". This file must also be added to your project with the following contents:
#!/bin/bash
ASSEMBLY=example.dll
SCL=rh-dotnet20
DIR="$(dirname "$(readlink -f "$0")")"
scl enable $SCL -- dotnet "$DIR/$ASSEMBLY" "$@"
 
Note that you must change the ASSEMBLY= line with the name of your application.
 

Three Small Steps

That's it for the tweaks necessary. In every case, you'll simply:
  1. Add the tiny section to your *.csproj file.
  2. Add the "standalone.sh" script to your project directory.
  3. Edit one line in that script.
 

Building the Code

After that, you use dotnet publish to prepare your code for containers, using the following command:
dotnet publish -c Release -r rhel.7-x64 --self-contained=false

Building an Image

Finally, add a file, "Dockerfile", with the following contents -- again, adjusting the file name to fit your application:

FROM registry.access.redhat.com/dotnet/dotnet-20-runtime-rhel7
ADD bin/Release/netcoreapp2.0/rhel.7-x64/publish/. /app/
WORKDIR /app/
EXPOSE 5000
CMD ["scl", "enable", "rh-dotnet20", "--", "dotnet",  "example.dll"]

Running the Image in a Container

Now we can build and run the application, such as this example:
docker build -t example .
docker run -d -p 5000:5000 --name example example
 

Conclusion

While there are some small changes needed to get your .NET Core 2.0 application running in a RHEL-based container, the payoff is worth the effort. As Cloud Native Computing and microservices become more common, this knowledge will allow you to contribute to this new frontier. If you want to learn more about this trend, check out Red Hat OpenShift, a Platform as a Service (PaaS) for running scalable microservices.

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Last updated: February 5, 2024