0

I'm starting to understand the naming conventions for the .NET stack cross-platform. Particularly this page explained it well: http://blog.tonysneed.com/2016/01/22/ef6-asp-net-core-mvc6/

I'm starting a personal project which will be completely greenfield and see it as an opportunity to learn all these new technologies. However, I want to re-use code from other MVC5 applications that use well known libraries. Especially for the infrastructure & plumbing I used some well-known libraries such as StructureMap, AutoMapper and for data persistance EF (EF 4/5).

Since there is no restriction on what version I should use, should I start from scratch and use the latest ASP.NET Core 1.0, .NET Core 1.0 along with EF Core 1.0 or is the only advantage from using only that it will be cross-platform? In other words, if I am never going to run this on anything but Windows AND want minimum pain with library incompatibilities do I stick with .NET4.6?

I basically want to use this opportunity to be able to learn the new stuff without impacting on future portability for my application. Will MS eventually make .NET Core 1 the default even on Windows?

Peter
  • 5,455
  • 7
  • 46
  • 68
user183872
  • 767
  • 2
  • 6
  • 20

2 Answers2

2

It doesn`t look MS is going to decide between the two because: .NET Core is essentially a fork of the NET Framework

In fact when you want to get it from official source you will be still facing your dilemma.

Asp.net core has a Go Live license, Microsoft will give support and is ready for production, which to choose?

Diclaimer: The rest of my answer could be opinion based...

If you don`t have constrains, e.g. you need still unsupported features like SignalR, I can share my similar experience so far:

I started with a core mvc6 web api

When I needed WCF it was not so easy -> see here

Then had to use a 4.5 framework targeted class library -> you can easily now reference those and all the wrap around it will be automatically done in visual studio

I had to find more ways through IIS publishing obstacles -> for example

Bottom line:

most of the issues where solving alone with new frequent releases

the feeling I had at the very beginning that I would jump out of it as soon as a blocking implementation arise, was changing in more and more confidence that actually you can have a flexible solution the more you learn it.

I can only add that you may want to go for a quick read of the documentation and have more clues

Community
  • 1
  • 1
vinjenzo
  • 1,490
  • 13
  • 13
  • So in summary is there any point in not using .NET Core 1.0 with bleeding edge/greenfield development? – user183872 Feb 01 '16 at 13:20
  • disclaimer still on: I dont see any and I like it, but everybody has different business reasons behind similar dilemmas – vinjenzo Feb 01 '16 at 13:34
  • https://learn.microsoft.com/en-us/dotnet/articles/standard/choosing-core-framework-server – vinjenzo Apr 06 '17 at 08:20
2

I went through this debate and settled on .NET Core; six months down the line and some production deployments later, I am convinced it was the right decision. Here are a few questions which may clarify your decision:

  1. Are you building a back-end service which matches .NET Core's 'sweet spot' - ie. a website or web/REST API or both? In my experience, .NET Core is perfect for this, and already works well, though EFCore is still maturing and the tooling is still changing.
  2. Do you want to build WCF services and other Windows-specific technologies? Generally you want to stick with the full .NET framework, as stated here. It is possible with a bit of work to call WCF services from a .NET Core Web API.
  3. Message queues - RabbitMQ now has .NET Core support, I think MSMQ you may have a problem - at best you will need to reference the full framework libraries.
  4. If you require any Windows-based GUI - WCF or Winforms - use the full .NET framework.
  5. Building background processes which run as Windows services - generally use the full .NET Framework, not supported in .NET Core, though you could write it in .NET Core and build a full .NET service wrapper for it - probably now worthwhile unless you also want to be able to run the process on other platforms.
  6. If you want the option of running cross-platform (I did), you must .NET Core.
  7. If you want to use Docker for deployment (as I have) - .NET Core seems to have more focus on this but both work and both are fully supported in the new Windows 2016 native containers.

Hope that helps.

Peter
  • 5,455
  • 7
  • 46
  • 68