Important Update
In this article, we are going to review some arguments you may have to consider before adopting either .NET Core or .NET Framework for your incoming project. Rather than to be a simple technical point of view, the final decision is mostly motivated by many other considerations.
Quick recap .NET Framework and .NET Core .NET Framework were in the market for so long years ago, 2 decades soon. It was designed to run exclusively on desktops or servers running the Windows operating system. Microsoft released different versions over time, some versions are just updated at the top of the existing version, they brought with new features, and sometimes it was entirely rebuilt from base to review the core architecture of the previous version.
This was the case during the major switch from version 1 to version 2 or from version 2 to version 4. From a technical point of view .NET Framework comes with the following components: – the main programming languages are C#, VB.NET ( lately F# becomes the reference for functional programming on . NET), net compilers, and net runtime environment – ASP.NET (Webforms and MVC later on) – Windows forms and WPF later on – WCF for service-oriented architecture, replacing basic ASMX services. – Workflow Foundation (a complete framework for business process management engine).
.NET Core came to the market with the idea of cross-platform applications (in the same way as Java did from the beginning). This time, Microsoft chose the open source way and opened up the technology to Linux, Mac, or any supported operating systems. It was developed around the concept of the kernel on which can be plugged into many components later on and has C# as the main programming language.
The latest stable version is 2.0 at the time of writing. At the highest level, one of the main differences between them is the way developers interact with the environment. In a few words, dealing with .NET Framework (and so the tools gravitating around it) is a plug-and-play device.
Your EDI or IIS is taking care of a bunch of loads of backgrounds. Since its beginning, .NET Core is slightly tricky for those who have the habit to use ready-made tools. You surely remember how tedious was the process when initializing the .NET Core project.
A part of dealing with the DotNet command-line utility to create or to publish the project, we have to manually operate any critical dependencies by editing the project JSON file. .NET Core is priorly designed to be used in a cross-platform context and especially reaching out to cloud app services.
The goal of this article is not to give preferential treatment to one framework over the other, we’ll stay very neutral in our arguments and will explain why one framework would be the best compared to the other one according to the case.
The very natural choice, regardless of any consideration, is the technical programming skill and the team’s background. It would be obvious for someone who dives into the .NET framework for decades to pick up .NET Framework.
For younger people discovering programming recently with .NET Core, they would go for that one without no doubt, that is the logical choice after all. So both of them feel confident in their skills and have a certain idea of how they would drive the app development with each respective framework.
However, beyond that good grasp on each framework, they will come across issues later on if they don’t perform serious analysis at the project beginning.
Therefore they should acknowledge that the app has to conform to all of the external requirements. For example, if the app is intended to use WWF to manage a workflow process engine, the right choice is .NET Framework, and forcing it to run in .NET Core may be a disaster for the whole project.
If the software you’re going to develop is a Windows desktop GUI application type or Windows 10 UWP app, there are no more options than using .NET Framework. It will perform well on Windows and can make the most of this operating system either choosing the client profile or the full .NET framework. .Net Core has a lack of capabilities on this site at the time of writing.
So to avoid any issue, later on, we definitely advise you to go for .NET Framework. If the application doesn’t require any particular Windows features, you have now to seriously think about what .NET Core can provide to you in terms of flexibility.
Suppose that you’re dealing with several operation systems (Linux-based, MacOSX, Windows), the .Net core is the only way to share the executable app between those platforms. Net framework is not able to handle that since it is only for computers running MS Windows OS.
Your plan is now to develop a Website. Consider first what kind of website it is: an asp.net web form, an asp.net MVC? Asp.net web form only works on .NET Framework-based while asp.net MVC can be hosted by both frameworks (.Net core deals with asp.net Mvc as from the 6th version – also named asp.net core).
If you’re going to deploy a service-oriented application – so handling web services – you have to think more than once because both platforms are now two serious candidates, each one has its pro and cons. For WCF services, the .NET framework coupled with IIS offers the best results since so long years ago, while the .NET core is not really still mature on that point.
However, the .NET Core community works hard to catch up this late and we hope it will become stable as soon as possible. This last point leads us to the next section: hosting infrastructure considerations.
As said earlier infrastructure needs to be discussed when designing an app especially when it requires to be hosted on a server. IIS is the most famous web server on Windows (even it does more rather than a simple webserver). IIS can host the .NET Framework and .NET Core-based app.
In a production environment, IIS has always hosted on a windows server operating system (either on-premise or in the cloud). And who said windows server should be prepared for a valid Windows server license, in other words, budget. We will talk about the budget later on in the next section.
Since .NET Core is cross-platform, it comes with a lightweight cross-platform and open-source web container/web server named Kestrel and it is supported by any platform where .NET Core was priorly installed. Kester is free and has already proven that it supports massive loads at scale. It can be coupled with a VPS reverse proxy server IIS, Nginx or Apache.
Therefore if you imagine serving requests from non-Windows OS as a future alternative, .NET Core is the best choice for you. When the development environment is other than the Microsoft Windows platform, .NET Core is your unique choice and one of the .NET Core essences is exactly to allow the developer to build apps on non-Windows computers.
During the development stage, you can use the VS Code IDE on Linux or Visual Studio For Mac/ VS Code on a Mac computer. .NET Core project will automatically download platform-specific requirements for you. And if for one or some reason you need to host your app in a Linux VPS (either virtualized or not), the only option is to develop the app using .NET Core.
When you’re designing your apps it also makes sense to list all external components on which you’re quite keen and how well they are supported by each framework. Let’s consider that your favorite RDBMS is an SQL server.
You need a driver to be able to interact with it from your c# code. .NET Framework comes with a very stable driver (System.Data client) which delivers a good result at scale. However, for .NET Core running on a Linux or macOS server, you should acknowledge how does it behave on such platforms.
Let’s consider the case you do assembly loading into the SQL server database, in this case, the only option is using .NET Framework. In general, rules, when your app will have a close dependency on MS Windows operation system (for example using the registry key, interacting with a third party library or specific vendor device), it’s better to use .NET Framework.
Delivering the application in a short delay of time may be the big challenge you’re facing. Depending on the project complexity or on external component integration, the .NET Framework may be the best choice.
This is because many tools and facilities already exist in the .NET Framework while things are not much as easier to manipulate in .NET Core. As an example, .NET Core tends to use a bunch of command lines from creating a new project, getting dependencies, building it, and finally firing the deployment.
This is a lot of pain when working on MACox or Ubuntu workstation. Facing that, the community tries to bring helpful tools to accelerate developer productivity and it would be easier to use them over time.
According to the market statistics, it is also easier to hire a senior .NET Developer (so .NET Framework) than a senior level on .NET Core. By Hiring a rare resource, you are aware that if he leaves the boat your project will be in pain, so you need to be prepared to ensure having at least one backup. This may increase your budget or add an additional delay in your forecast.
Depending on the context you are in and knowing the roadmap of your company, it is always interesting to row your choice following that vision.
At the time of writing, we don’t know what would be the .NET Framework in the next ten years, but it is more obvious that .NET Core has a good perspective for the next incoming years.
Microsoft began to engage the reverse gear when their teams decided to release some frameworks to be open-sourced, this was a major sign of their new orientation.
A few months ago they published a Linux version of the well-known Microsoft SQL Server Database 2017, this was never seen before since the crowd thought that SQL Server will be exclusively for Windows OS forever.
Finally, let us remember that .NET Core maintains version compatibility between lower and upper revisions. Any .NET Core 1.0 program would work fine in any later version – only in this way – .NET Core 2.0 (the actual latest dot net core version) program may fail if we’re trying to run it over .NET Core 1.0 framework.
For the .Net framework, there may be many cases where two versions are not compatible at all and as a workaround, we have to do assembly routing. Switching your program from .NET Framework to .NET Core is not possible since they are not the same thing at all. There’s no hope to get it working without any serious change.
On .Net Framework, developers may encounter some errors when they tried to use the dynamic expression on the top of .NET 3.0 or async/await/Task patterns on .NET 3.5. .NET Core inherits the latest features of C#. So good news for C# sharp developers: they can still use the famous Linq extension methods, dynamic types, auto-properties, or tuple deconstructions since c# 7.
Making a decision is not always easy as it seems to be, many factors need to be evaluated at the earlier stage of your project. Generally, there’s not a rush to jump from .NET Framework to .NET Core from one day to another.
In our humble opinion, we are encouraging people to experiment with new technology. Of course, this change needs to be carefully prepared: recycle your learning curves, resources and project management forecast, budget consideration, and technical proof of concept – showing that .netcore technology can really do the job. If you take care of all details exposed so far, choosing which framework suits well your project will not take a very long time.
Also, remember that there’s no magic formula conditioning the choice, and the final decision would be made on a case-by-case basis.
About the Author
ByteScout Team of Writers
ByteScout has a team of professional writers proficient in different technical topics. We select the best writers to cover interesting and trending topics for our readers. We love developers and we hope our articles help you learn about programming and programmers.
1. Clean up formatted text in Google Docs When you copy and paste the text into your documents it is often passed along with various...
ByteScout PDF Tools are now connected to Zapier! The functions available in our tools can be automated with other services on the Zapier platform. You...
