There are two apparent approaches to go for server-side applications with .NET. These are the .NET Framework and .NET Core. They both share common components and codes between them. Yet, there are many stark differences between them, and the logic to choose either one of them depends on what you are looking for. This blog will discuss why and when a particular .NET technology is preferred over the other.
You have .NET Core in place when
- You need cross-platform
- You are focused over microservices
- You have Docker containers
- You require high-performance and scalable systems
- You require side-by-side .NET versions
You have .NET Framework in place when
- Your app already uses .NET Framework
- Third-party .NET libraries or NuGet packages that are not supported by .NET Core
- Your app has .NET technologies that do not support .NET Core
- Your app has a platform that doesn’t support .NET Core
When .NET Core is best?
The given below sections will discuss in details on why it is best to go with .NET Core
Cross-platform requisites
If the application requires to be run on multiple platforms like Windows, Linux, or Mac, you must use .NET Core. It offers complete support to all these operating systems as well as a development workstation.
Visual Studio has an Integrated Development Environment (IDE) for both Windows and macOS. The Visual Studio Code runs on macOS, Linux, and Windows, as well. It also supports .NET Core, IntelliSense, and debugging.
Third-party editors such as Sublime, Emacs, VI, and others work very well with .NET Core. These editors can get IntelliSense using Omnisharp. You may want to avoid a code editor and directly use the .NET Core CLI tools, which is compatible with all the supported platforms.
Microservices architecture capabilities
Microservices architecture enables a mixture of technologies across the service boundary. This mixture allows for a gradual adaptation of .NET Core for new microservices that can align with other microservices or services. For e.g., you can combine microservices or services developed with .NET Framework, Java, Ruby, or other monolithic technologies.
There are plenty of infrastructure platforms available out there. Azure Service Fabric is built for large and complex microservice systems. The Azure App Service is an excellent choice for stateless microservices. As explained in the subsequent Containers section, the Microservices alternatives based on the Docker can fit any kind of microservices approach. This makes .NET Core an ideal candidate for hosting your microservices when it comes to getting support from platforms.
Containers compatibility
Containers are very commonly combined with microservices architecture. Containers can be applied to any web application or services that adhere to any architectural logic. The lightweight nature and modularity of .NET Core make a better choice even though the .NET Framework can be used for Windows containers.
When you are creating and implementing a container, the image size is much smaller in the case of .NET Core than .NET Framework. Since .NET Core is cross-platform, you can use server apps in Linux Docker containers.
For e.g., the Docker containers can be hosted in Linux or Windows infrastructure or in a cloud service such as Azure Kubernetes Services. The Azure Kubernetes Service is capable of managing, orchestrating, and scale container-based applications in the cloud.
You require high-performance and scalable systems
When you are looking for the ultimate performance and scaling it up to the max, .NET Core and ASP.NET Core are the best bets. The High-performance server runtime of .NET Core on Windows Server and Linux makes it a top-notch performing web framework.
Performance and scalability matter, especially in the case of microservices architectures, where several of microservices may be deployed. In the case of ASP.NET Core, the systems have a much lower number of servers/VM(virtual machines). This results in cost-effectiveness in infrastructure and hosting.
You require side-by-side .NET versions
If you want to install applications with dependencies on different versions, .NET is the ideal candidate. The .NET Core offers side-by-side installations of different .NET Core versions on the same machine. This type of setup allows running of multiple services on the same server, each of them having its own version of .NET Core. It also reduces the risks and saves budget in application budget and operational costs.
When .NET Framework is best?
.NET Core may look like the ultimate winner for new applications and app patterns. Still, the .NET Framework is chosen in many different scenarios, and it is not always being replaced by .NET Core for all server apps.
Existing .NET Framework applications
Generally, you don’t have to migrate the current application to .NET Core. In fact, it is observed that .NET Core is used to extend the current application.
Third-party .NET libraries or NuGet packages that are not supported by .NET Core
The libraries are quick to adapt to the .NET Standards. This allows for more comfortable code sharing across all .NET implementations, which includes .NET Core. With the launch of .NET Standard 2.0, this has become even more straightforward.
- API surface is much large now
- It also introduced a .NET Framework compatibility mode. This enables the .NET Standard/.NET Core projects to reference the .NET Framework libraries.
This means if there are libraries or NuGet packages that technologies that are not available in .NET Standard/.NET Core, the .NET Framework comes handy.
Your app has .NET technologies that don’t support .NET Core
Not all .NET Framework technologies are available in .NET Core. They might become available in the later release of .NET Core. But some of them don’t apply to the new application patterns which are relevant to .NET Core and may never become available in the future as well. The given below list talks about the technologies that are generally not found in .NET Core.
- The ASP.NET Web Forms are only available in the .NET Framework. ASP.NET Core can’t be used to create ASP.NET WebForms. Also, there is no plan to bring it to .NET Core.
- ASP.NET Web pages are also not part of the ASP.NET Core.
- WCF server implementation is exclusively available with .NET Framework. It may become available in .NET Core in the future, but it is currently not available.
- The workflow related services like Windows Workflow Foundation, Workflow Services, and WCF Data Services are only going to be available in the .NET Framework and will never be part of the .NET Core.
- Languages like Visual Basic and F# are not completely supported in .NET Core.
Your app has a platform that doesn’t support .NET Core
There are some Microsoft and third-party platforms that don’t support .NET Core. Also, some Azure services have SDK that is not yet available for .NET Core. However, this could be a temporary phase as Azure services use .NET Core. You may use the REST API instead of the client SDK.
Conclusion
Ace has worked on both technologies, and from our experience, we can say that these technologies are better suited for distinct specific objectives. If you are still not sure how to choose between either one of them, you can reach out to us for a no-obligation consultation call.
