As a developer, when should I still use .NET Framework, instead of .NET Core or Xamarin?
The pick between the different frameworks should not be based on which has a better architecture but should be based on the strengths and weaknesses of the technologies and which system has better solution for the task at hand, for your particular context and application or subsystem or microservice type. The latest and greatest technologies usually have a more modern architecture, but that doesn’t mean that you should always pick the latest. There are many situations where a more mature platform is still a better choice until the new frameworks grow further and get more mature, or simply because certain legacy sub-frameworks are only supported by the .NET Framework.
In summary, you still might need to use the .NET Framework in a large variety of cases, as explained below:
- NET Core running on the .NET Framework/CLR. Remember, if you need to consume traditional/legacy libraries based on the .NET Framework, you can still use ASP.NET Core with its own benefits (MVC+WebAPI unification, self-hosting, cloud-ready environment-based config system and built-in dependency injection) but running it on top of the .NET Framework (traditional CLR). In this case, you will lose the intrinsic .NET Core and CoreCLR benefits (cross-platform and modular/lightweight framework) until you eliminate those dependencies with legacy libraries, but you could do that in the future.
- NET Web Forms applications. As of June 2016, ASP.NET Web Forms is only supported/provided by the full .NET Framework, so you cannot use ASP.NET Core / .NET Core for this scenario.
- Visual Basic support. As of June 2016, Visual Basic is not supported by .NET Core and ASP.NET Core, although it is in the future roadmap.
- NET Web Pages applications. As of June 2016, ASP.NET Web Pages is only supported/provided by the full .NET Framework, so you cannot use ASP.NET Core / .NET Core for this scenario. Although Web Pages is in the future roadmap.
- NET SignalR server/client implementation. As of June 2016, ASP.NET SignalR (server and client implementation) is only supported as RTM by the full .NET Framework, so you still cannot use ASP.NET Core / .NET Core RTM for this scenario in production, yet. Although, SignalR’s implementation is in the ASP.NET roadmap and in preview state and being currently developed at github.com/aspnet/SignalR-Server (Server side) and github.com/aspnet/SignalR-Client-Net (Client Library) and will be RTM released in the near future.
- Desktop apps including Windows 7 and Windows 8. If you want to build Desktop applications that run on Windows 7 through Windows 10, you need to use the .NET Framework.
- WPF (Windows Presentation Foundation) applications. WPF is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
- Windows Forms applications. WinForms is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
- WCF services implementation. Even when there’s a WCF-Client library to consume WCF services from .NET Core, as of June 2016, WCF services/server implementation is only supported/provided by using the full .NET Framework, so you cannot use .NET Core for this scenario. Microsoft is considering this scenario for the future roadmap, but not confirmed, though.
- WF (Windows Workflow Foundation) workflows implementation. WF service implementation is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
- Workflow Services. Workflow Services (WCF+WF in a single service) is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
- WCF Data Services (formerly known as “ADO.NET Data Services”). WCF Data Services is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
- Azure’s products that still don’t support .NET Core. As of June 2016, there’s a number of Azure products still not supported by .NET Core, like Service Fabric Stateful Reliable Services, Service Fabric Reliable Actors, and quite a few products where their client SDK requires the full .NET Framework. However, now that the .NET Core RTM has been released (June 2016), most of the products in Azure will provide compatibility with .NET Core. In regards Azure products remote consumption even when the client SDK might still be not available for .NET Core, you can always use the REST API that most Azure products provide from .NET Core, as well.
- Need to use third party .NET libraries or NuGet packages not available for .NET Core – Use ASP.NET Core running on the .NET Framework for this scenario, or just the .NET Framework. Some of the third party Nuget packages might not be available on .NET Core yet.
When should I not use .NET Framework 4.x?
- When running across OS platforms is a requirement for your system or sub-system/microservice. Clearly, the .NET Framework is only supported by Windows. If you need to run on a different OS, you cannot use the .NET Framework but you should evaluate and choose between .NET Core or Mono.
- In Bounded loosely-coupled services or web applications that require the best possible performance and scalability and can be implemented with .NET Core – This case is similar to “Microservices” and “Best performant and scalable systems” in the “When should I use .NET Core?” section of this document.
- (Evaluate) Some long-term mission-critical and core-business subsystems/microservices. In this type of sub-systems or microservices that are strategic for the business and will be evolving for many years, you usually want to invest on technologies that will be getting the most investment and innovation from the vendor so that will improve your core system. Even when the .NET Framework will be evolving and getting investment from Microsoft, it’ll be at a slower pace than with .NET Core due to its own nature (The .NET Framework is older and not designed with a modular architecture that can be evolving at a much faster pace, autonomously per NuGet package). Therefore, you should evaluate sub-system per sub-system or microservice per microservice, and if possible, use .NET Core and ASP.NET Core. If it is not possible because of incompatibility issues with legacy libraries, then use ASP.NET Core running on the .NET Framework or simply use the .NET Framework, but try to evaluate first if .NET Core fits for your new sub-system or microservice level, so migrations in the future will cost less. Note that we state “some subsystems/microservices” and not a whole mission-critical application, as with .NET Core 1.0 it is highly probable that some parts of your system cannot be implemented and you still need to use the .NET Framework for that particular subsystem/microservice. In summary, do not use the .NET Framework if what you want to do can be perfectly done with .NET Core, like many front-end web sites or microservices.
- When using an Opened Source Framework is a requirement for you.