​Since ASP.NET Core 2.2 was released I have been working on getting all my different applications updated and using in-process hosting. I pretty quickly hit an issue with an application that uses SQLite. As soon as the application tried to access the database I ended up with the following error.

After some Googling, I found an issue on GitHub that details the problem. It turns out that when the application gets its current directory it is returning the path to the IIS process that is hosting the application instead of the directory when the application is.

On another GitHub issue, I found a link to a recommended workaround. Add the following class somewhere in your application. This code comes here.

Given the diversity of operating systems supported by Docker and the differences between .NET Framework and .NET Core, you should target a specific OS and specific versions depending on the framework you are using.

For Windows, you can use Windows Server Core or Windows Nano Server. These Windows versions provide different characteristics (IIS in Windows Server Core versus a self-hosted web server like Kestrel in Nano Server) that might be needed by .NET Framework or .NET Core, respectively.

For Linux, multiple distros are available and supported in official .NET Docker images (like Debian). In the image below  you can see the possible OS version depending on the .NET framework used.

You can also create your own Docker image in cases where you want to use a different Linux distro or where you want an image with versions not provided by Microsoft. For example, you might create an image with ASP.NET Core running on the traditional .NET Framework and Windows Server Core, which is a not-so-common scenario for Docker.

When you add the image name to your Dockerfile file, you can select the operating system and version depending on the tag you use, as in the following examples:

You should use .NET Core, with Linux or Windows Containers, for your containerized Docker server application when:

•  You have cross-platform needs. For example, you want to use both Linux and Windows Containers.
•  Your application architecture is based on microservices.
• You need to start containers fast and want a small footprint per container to achieve better density or more containers per hardware unit in order to lower your costs.
  

In short, when you create new containerized .NET applications, you should consider.NET Core as the default choice. It has many benefits and fits best with the containers philosophy and style of working. An additional benefit of using .NET Core is that you can run side by side .NET versions for applications within the same machine. This benefit is more important for servers or VMs that do not use containers, because containers isolate the versions of .NET that the app needs. (As long as they are compatible with the underlying OS.)

You should use .NET Framework for your containerized Docker server application when:

•  Your application currently uses .NET Framework and has strong dependencies on Windows.
•  You need to use Windows APIs that are not supported by .NET Core.
• You need to use third-party .NET libraries or NuGet packages that are not available for .NET Core.

Using .NET Framework on Docker can improve your deployment experiences by minimizing deployment issues. This “lift and shift” scenario is important for containerizing legacy applications that were originally developed with the traditional .NET Framework, like ASP.NET WebForms, MVC web apps or WCF (Windows Communication Foundation) services.

I​n the past, solution delivery was oriented around the waterfall model. Development and delivery of applications was typically divided into many separate steps, such as gathering requirements, writing code, packaging, performing tests, installing the software, etc. Each step was typically owned by one team, which was responsible for only that part of the process, ignoring others.

In other words, developers were focusing only on code development, a process that could last months or even years, leaving solution delivery to the operations teams. New solutions and changes were implemented as one-off revolutions, which required heavy planning and change management processes. This approach had many drawbacks. It didn’t scale well, nor was it immune to quickly changing requirements. It didn’t promote cooperation in solution delivery but promoted competition and blaming others. Any mistake made at the beginning of analysis was stuck with a project until its conclusion, and in most cases entire solutions were
becoming obsolete even before they started yielding any benefits.

The DevOps methodology addresses organizational issues related to the software production process. Since it comes directly from the agile movement, it promotes incremental, iterative solution delivery. DevOps is not about a dedicated team nor is it governed by a well-defned set of rules or tools.