Skip to main content

.NET Core or .NET Framework together with Docker and Containers on Azure

In this post, I will try to find answers and guidance for technical people that needs to decide if they shall use .NET Core or .NET Framework inside Docker containers on Azure. The same answer is applicable for on-premises, because Docker runs in the same way on Azure or on-premises.

The directions from Microsoft related to this topic are clear. The default option shall be .NET Core. From this way, .NET Core is design in a such a way that is align with container concepts. For example the footprint was reduced drastically in comparison with .NET Framework.

One interesting fact that people do not know is related to the type of Windows image that you need to use when you use .NET Core or .NET Framework together with containers. When you use .NET Framework you need to use a Windows Server Core. This image is heavier than Windows Nano Server. This can have a direct impact at infrastructure and resources requirements. There are many things to say why Windows Nano Server is better, a few things you can find below:

  • VHD image is ~93% lower
  • 80% fewer reboots
  • 92% fewer critical bulletins  

Now, let's see some cases when you should go with one or another.

.NET Core when you are using micro-services concept
First, when you design an application that is based on micro-services concept you will want to go with .NET Core. A micro-service architecture is based on a high number of services that runs in parallel. This requires you to have the footprint of the service as small as possible.
You do not want the container image to be 4.5GB, because of it.

.NET Core for cross-platforms
Secondly, if you know from the beginning that your containers use Linux also, not only Windows, then .NET Core is your only option. In contrast with .NET Framework, .NET Core can run on both platforms. There is not too much to do with .NET Framework on Linux. Do not even thing to try to use Mono, because you will end up in a situation where the only option is migration to .NET Core.

.NET Core for cost optimization
Each instance of a container consume infrastructure resources. It is not the same thing to have a container that has 4.5GB of disk consumed or 200MB. Even if your hosting your container inside the cloud, you will need to pay for each MB and for each CPU cycle that you are consuming. Because .NET Core is using less resources that .NET Framework, it is a much better candidate for containers.

Still, there are some things that can force you to use .NET Framework. But don’t be panic. Remember that you can have in the same deployment different types of containers. So, if you are required to use .NET Framework, you can use it only for the containers where it is strictly necessary.

.NET Framework for strong dependencies to OS (Windows)
When the application has strong dependencies to Windows, there is no other option that to go with .NET Framework. This kind of OS dependencies cannot be found on .NET Core and will not allow you to communicate with OS in the same way as would happen with .NET Framework.

.NET Framework for .NET libraries that are not available for .NET Core
Unfortunately, many libraries are not available for .NET Core. Just looking on Nuget, you'll found many packages that are not compatible with .NET Core yet and there are no signs that this is going to change. Beside this, if your application is using legacy libraries than you are stuck. Chances that this kind of libraries to be ported to .NET Core are almost zero. If you want a legacy library to be migrated to .NET Core than you might need to do it by yourself.

.NET Framework when you need to use Windows API
.NET Core is a cross platforms. In this context, there is no API that allows us to communicate with Windows API. If you find yourself in a situation when you need to make calls to Windows API, you should know from the beginning that .NET Framework is your only option.

.NET Framework for migration scenarios
If you find yourself in a situation when you need to do a migration to an existing application to container than you need to design a migration plane where risk are controlled and you have clear milestones. Do not jump and say that you need to rewrite the system. You can make small steps and even migration to containers together with .NET Framework might be enough to resolve the current problems.

.NET Framework when technology is not available in .NET Core
There are technologies that are not yet available in .NET Core. This kind of constraints can force you to go with .NET Framework. A part of the current technologies that are not yet available in .NET are:

  • VB & F# (because of lack of support in VS2017)
  • Workflow Foundation
  • WCF
  • ASP.NET SignalR
  • ASP.NET Web Pages
  • ASP.NET Web Forms

Take into account that new versions of .NET Core might come with some changes in this area.

 If you evaluate your projects requirements in the right way, I'm sure that you will find a way to go with Docker and .NET. Worst case that can happen is an hybrid solution that has both .NET Core and .NET Framework. More about this kind of solution I will talk in the next post.



Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…