Topic navigation

Blog Articles

.NET Core

NuGet is the .NET package manager. By default, the .NET Core SDK will use packages from the nuget.org website.

In this article, you’ll learn how to deploy a NuGet server on Red Hat OpenShift Container Platform (RHOCP). We’ll use it as a caching server and see that it speeds up our builds. Before we get to that, we’ll explore some general NuGet concepts and see why it makes sense to use a local NuGet server.

Red Hat OpenShift implements .NET Core support via a source-to-image (S2I) builder. In this article, we’ll take a closer look at how you can use that builder directly. Using S2I, you can build .NET Core application images without having to write custom build scripts or Dockerfiles. This can be useful on your development machine or as part of a CI/CD pipeline.

We are very excited to announce the general availability of .NET Core 2.2 for Red Hat Enterprise Linux and OpenShift platforms! This general availability is in lock-step with Microsoft’s release yesterday.

.NET Core is the open-source, cross-platform .NET platform for building microservices. .NET Core is designed to provide the best performance at scale for applications that use microservices and containers. Libraries can be shared with other .NET platforms, such as .NET Framework (Windows) and Xamarin (mobile applications). With .NET Core you have the flexibility of building and deploying applications on Red Hat Enterprise Linux or in containers. Your container-based applications and microservices can easily be deployed to your choice of public or private clouds using Red Hat OpenShift. All of the features of OpenShift and Kubernetes for cloud deployments are available to you.

.NET Core 2.2 continues to broaden its support and tools for application development in an open source environment. The latest version of .NET Core includes the following improvements:

.NET has APIs for locating special folders that can be used for application and user configuration and data storage. They provide a convenient, portable way to make cross-platform applications find the appropriate folders on different operating systems. We’ll look at how Environment.GetFolderPath, Path.GetTempPath, and Path.GetTempFileName behave on Linux.

In an effort to improve security, browsers have become stricter in warning users about sites that aren’t properly secured with SSL/TLS. ASP.NET Core 2.1 has improved support for HTTPS. You can read more about these enhancements in Improvements to using HTTPS. In this blog post, we’ll look at how you can add HTTPS to your ASP.NET Core applications deployed on Red Hat OpenShift.

Before we get down to business, let’s recap some OpenShift vocabulary and HTTPS fundamentals. If you are familiar, you can skip over these sections.

OpenShift, pods, services, routes, and S2I

OpenShift is a Kubernetes-based open-source container application platform. A Kubernetes pod is a set of containers that must be deployed on the same host. In most cases, a pod consists of a single container. When we run the same application in several pods, a service does the load balancing across those pods. A route makes a service accessible externally via a hostname.

In this blog post, we’ll set up Microsoft SQL Server on Red Hat OpenShift. We’ll use SQL Server to store data for a simple ASP.NET Core application running in a container deployed on OpenShift that manages a list of contacts. When we have that set up, we’ll use SQL Operation Studio to connect to the server running on OpenShift from our developer machine.

ASP.NET Core is the web framework for .NET Core. Performance is a key feature. The stack is heavily optimized and continuously benchmarked. Kestrel is the name of the HTTP server. In this blog post, we’ll replace Kestrel’s networking layer with a Linux-specific implementation and benchmark it against the default out-of-the-box implementations. The TechEmpower web framework benchmarks are used to compare the network layer performance.

When you want to do automated tasks for builds and deployments with Red Hat OpenShift, you might want to take advantage of the OpenShift REST API. In scripts you can use oc CLI command which talks to the REST APIs. However there are times when it is more convenient to do this directly from your C# code without having to invoke an external program. This is the value of having an infrastructure platform that is exposed as services with an open API.

If you want to call the API from your C# code, you have to create a request object, call the API, and parse the response object. The upstream project, OpenShift Origin, provides a Swagger 2.0 specification and you can generate a client library for each programming language. Of course, C# is supported. This isn’t a new approach, Kubernetes has a repository that is generated by Swagger Codegen.

For C#, we can use Microsoft Visual Studio to generate a C# client library for a REST API. In this article, I’ll walk you through the process of generating the library from the definition.

Containers are the new way of deploying applications. They provide an efficient mechanism to deploy self-contained applications in a portable way across clouds and OS distributions. In this blog post we’ll look at what OpenShift brings for .NET Core specifically.

Kubernetes and OpenShift

Kubernetes is the de facto orchestrator for managing containerized applications. Google open-sourced Kubernetes in 2014 and Red Hat was one of the first companies to work with Google on Kubernetes. Red Hat is the 2nd leading contributor to the Kubernetes upstream project.

OpenShift is an open-source DevOps platform that is built on top of Kubernetes. It integrates directly with your application’s source code. This enables continuous integration/continuous deployment (CI/CD) workflows. Tools are available to scale and monitor your applications. The OpenShift Catalog makes it easy to setup middleware and databases. OpenShift comes with comprehensive documentation to install and manage your installation. It can run on-prem and on public clouds such as AWS, GCP and Azure.