As a developer, when should I use .NET Core? When should I *not* use .NET Core? Here are the four typical scenarios that you should *not* choose .NET Core.
1. Current .NET Framework applications in Production / Migrations
In most cases, you still don’t need to migrate your current .NET applications like ASP.NET apps to run on .NET Core. Not just because the cost of the migration and code rewriting would be significant but also because as of today (2016) you’ll find that many of the third libraries that you are executing from .NET Framework code cannot be used from an app running on .NET Core.
However, if you want to start taking advantage of the new capabilities provided by ASP.NET Core (see the value-props from ASP.NET Core explained earlier in this doc), you can still migrate to ASP.NET Core but running on the traditional CLR from the .NET Framework. That would allow you to reuse legacy third party .NET libraries not compatible with .NET Core while taking advantage of new web capabilities and approaches in ASP.NET Core.
2. New large monolithic applications
If you are developing a large enterprise application that cannot be loosely coupled and composed by isolated components or services (like with a microservice architecture approach) chances are that as soon as you need to consume libraries that are compatible only with the .NET Framework, if you are using the .NET Core runtime it’ll be a stopper as those components/libraries that you need cannot be run on the CoreCLR runtime and with a monolithic approach it is difficult to isolate components/services with a single responsibility that could be running on .NET Core.
Note that this doesn’t mean that with .NET Core you always have to use a microservices approach and cannot build traditional architecture models (like layered or N-Tier). You can perfectly do it. The issue here is with libraries’ compatibility and allowed references per project/assembly/service.
A feasible approach here would be to use ASP.NET Core but running it on top of the .NET Framework and the traditional CLR, so you can consume any .NET library from the framework or third party. In the future you could eliminate those dependencies so it’ll be possible to run as a pure .NET Core application. But this refactoring task with a monolithic architecture won’t be as easy as if it had a loosely coupled architecture.
3. Need full capabilities of higher level frameworks like Entity Framework 6.x, WCF and Windows Workflow Foundation.
Even when .NET Core has several new libraries related (like EF Core or WCF for .NET Core) targeting part of those areas, yet in .NET Core 1.0 they don’t have all the functionality of their peers in the .NET Framework but are provided to make porting code easier for developers who need the capabilities provided by .NET Core.
Again, if you need libraries/functionality that is still not supported by .NET Core, the recommended approach is to create decoupled microservices using the full .NET Framework that eventually could be migrated to .NET Core so you get additional performance and scalability benefits for those microservices in the future.
4. Need sub-frameworks not supported by .NET Core.
If you need to use sub-frameworks like WPF, WebForms, WinForms or other frameworks not supported by .NET Core, you still need to use the .NET Framework. See the “When should I still use .NET Framework 4.x?” section for more details.
5. Possible frameworks to be ported to .NET Core
For a full list, take a look at CoreFX issues marked as port-to-core. Please note that this list doesn’t represent a commitment from Microsoft to open source all these components or even bring them to .NET Core — they are simply capturing the desire from the community to do so. That being said, if you care about any of the components listed above, consider participating in the discussions on GitHub so that your voice can be heard. And if you think something is missing, file a new issue.