0

.net Core or "clean" .Net for greenfield web project?

Having googled quite a bit, but not really found an answer to whether I should go for .Net core or "normal" .net for a greenfield web project? Given (important!) that its a project (HTML UI + mvc + db) thats never gonna run on anything but windows + IIS. Ever. Period.

For classic .net is all the stuff I know (various Nuget Libs) which has a bunch of functionality I need. For .Net core is??? (give that I DONT need any crossplatform stuff in this project. Ever. Period).

What confuses me is (in the context of the project I've sketched)

  1. if .Net Core is meant by MS to replace "classic" .Net in the future? Or live side by side?
  2. Does core (eventually) contain ALL the stuff in classic + more, or vica versa ?

Some of it is somehow touched in these posts Target .NET4.6 or .NET Core 1 for greenfield development? but thats before the new .Core 2.0 came out, so I revisit the question

:)

Toke Breer-Mortensen
  • 277
  • 2
  • 12
  • 4
    This is going to be opinion based, so not a good fit here. However, you have to have a good idea of what other libraries you might use. if those libraries work in .NET core, then you might consider using it. Otherwise, stay with the full .NET framework. – Erik Funkenbusch Aug 17 '17 at 15:20
  • It was afraid of getting the "opinionb based" label (and somehow agree), but from googlingg most answers I have been able to find has been focusing on crossplatform issues / benefits ect, so I hope that my question might raise issues / points I hadnt thought off (give the "one platform only"-context) :) – Toke Breer-Mortensen Aug 17 '17 at 15:39
  • 3
    If you need cross platform, then you want .net core for sure (you can do mono, but why bother). If you don't need xplat, and it's greenfield, my personal believe is to start with .net core.. it will probably take work to stay on it.. but with .net core 2.0 they've added a whole bunch of new api's from .net 4.x, so it should be easier. – Erik Funkenbusch Aug 17 '17 at 15:50
  • Something else to consider is performance, asp.net core might be your choice if you need raw performance. – WooHoo Aug 17 '17 at 16:59

2 Answers2

3

if .Net Core is meant by MS to replace "classic" .Net in the future? Or live side by side?

.NET Core is designed to be very side-by-side (.NET Framework is mostly in-place).

Does core (eventually) contain ALL the stuff in classic + more, or vica versa ?

No, there's no plan to make .NET Core a 100% superset of .NET Framework (WinForms, etc). There's also not a plan to make .NET Framework a 100% superset of .NET Core (some API may be more focused on being cross-platform and not make sense in .NET Framework, some may have been semi-experimental and declared to not pass muster)

.net Core or "clean" .Net for greenfield web project?

.NET Core and .NET Framework can (loosely) be thought of as a startup and a megacorp.

If .NET Core makes a bugfix in master you can choose to move to a daily build which fixes it. If .NET Framework makes a bugfix it's in the next version, or comes out on some Patch Tuesday.

When .NET Core 2.1 (or whatever the next number ends up being) comes out, and it has a feature you want, you can move to it right away, even on a webhost company. .NET Framework 4.7.1 is currently in preview, but you likely can't make use of any 4.7.1 functionality via webhosting companies, because they haven't installed it yet... and they might not for a while after 4.7.1 hits public release.

In .NET Core you can make an API proposal, see it go through the review process, and either write it yourself or wait for it to appear, and then (if you like) use it off of daily builds. .NET Framework is a bit more slow and methodical, and is happy to let its younger sibling take the risk with experimenting with new API.

.NET Core 1.0 (June 2016) added support for exporting and importing ECDSA keys using explicit curves. .NET Framework 4.7 (April 2017, 10 month lag) got that feature, and there are probably features that are .NET Core 1.0 -> .NET Framework 4.7.1 (14 month lag, and counting), and (as far as I can tell) ValueTask was added to .NET Core 1.0, and isn't in .NET 4.7.1-Preview.

.NET Framework, on the other hand, may have a deployment model that better matches what you want, and has "more" (but not "strictly more") API available.

So, it's a tradeoff. You need to decide what's important to you.

bartonjs
  • 30,352
  • 2
  • 71
  • 111
1

My advice is to go with "clean" .Net. Maybe you are going to use some technologies, libraries or NuGet packages that are not currently available for .NET Core.

jaaso
  • 1,405
  • 1
  • 9
  • 10