.NET Core: Hype vs Reality


I came across this post which might be of interest to the community:

May be come of the community members here can also weigh in to what has been said in the blog and discussion.


here we go yet again.
rather than “weigh in” and start yet another flame war, how about some real discussion about .Net core itself.the back and fourth hypefest, this or that is the “FUTURE” nonsense, that is dead, to what end?

the question of WCF was asked several times on soma’s blog, with no answer, and small list was offered and a link on the Dec 5th, saying a lot of discussion was going on here, I don’t real see much real activity on forum, which is sad, most of the real questions could have been answered watching the connect sessions. has anybody reading this heard of MEF, let alone is it in core or not?
it’s in System.ComponentModel.Composition, at some point I’ll just do a pull myself, if I can’t get an answer?


@sirinath , opps, sorry to make judgements, I’m no good at this commenting thing, I got carried away again and let the other “merge” thread cloud my judgement , thanks for the links, the last was just devastating, there’s no point in any further involvement here for me. good luck on your mono projects.
thanks again,I know what dharma means, but not sana but I bet it’s good too, great name I will remember it.


I’d actually like to hear what @richlander has to say :smile:


There are is a lot of good feedback and concerns raised in those posts and related comments.

There are a few core issues raised:

  • Will we see significant adoption of .NET Core?
  • Will .NET Core remain specific to the ASP.NET 5 server scenario?
  • Will porting to .NET Core be as expensive as expected?

Cross-platform, at least as an option, is something that many companies and individual developers have expressed interest in. I expect that we’ll see significant adoption of ASP.NET 5 in the first year and it will grow over time. That said, it will remain a great deal smaller than the user-base of the .NET Framework. For library developers, the “wait and see” approach that Frans suggests is a fine one. You can wait to see how many people ask for a .NET Core version of your library. Library developers that can support .NET Core more easily will likely do so more quickly. We use both of these approaches on our team. It’s smart.

The porting exercise will likely get easier over time. We intentionally started small with .NET Core, largely to make it available sooner. More libraries will get added on over time. Each new library that gets added will make porting easier. The .NET Framework will always be bigger than .NET Core and have more APIs, so some aspect of the porting exercise will always remain. I’m not trying to gloss over that.

I suspect that .NET Core will support more workloads over time. Right now, we’re focussed entirely on ASP.NET 5 and .NET Native. We want to make sure that both of those app workloads are production quality when they ship. We’ll look at other options after that. I understand that people would like a x-platform UI framework. It isn’t something that we are looking at right now. It isn’t so much a question of resourcing but focus. We have a strong desire to deliver what we’ve already promised.


Is core to be the new primary dev stack with full eventually being for legacy only?


The goal of the .NET Framework has always been to be the best dev platform for Windows. I think we achieved that. That goal for the .NET Framework isn’t changing.

A goal of .NET Core is to make much of the value of .NET available on Linux and Mac (in addition to Windows). That doesn’t include Windows-only features like COM or WinRT.

ASP.NET 5 is a good technology to focus on to answer this question. It is supported on both the .NET Framework and .NET Core. That’s not by accident. If the web app or service you want to write is going to require technologies that are Windows-specific, then the .NET Framework is a great choice. If the app requirements are more generic, then .NET Core may be the best choice.

A lot of .NET developers have built apps that take advantage of Windows-specific technologies. It’s important that we continue to improve the .NET Framework so that those apps continue to work great and get better.


So from a Microsoft only view, .NET full is for Windows only development while Core is for cross platform development or xcopy deploy?


@Shmuelie - yes, that’s a good description. You could also add open source as a benefit of .NET Core. Other than that, I think you have it covered.


I’m getting a little tired of this non-official remarks coming from MS employees, how well intended they are. The thing is that as an ISV I can’t make decisions based on what MS employees think, I have to know for sure what MS is going to do, as porting my ORM to .NET core isn’t simple, and it takes serious investment, I tried to express that in the article that’s linked in the OP (.NET Core==the future, but whose future is that?).

I have corresponded with several Microsoft employees from team devs to team leads about .NET core and what the future holds for ‘.NET’, and the general view is (but again, no official word!) that .NET core is ‘the future’. Sure .NET full won’t be killed tomorrow, but to me it’s simply as vague as you can possible get it: one MS employee says “it’s the future!”, another person says “.NET full will always be the best dev platform for windows”. Both can’t be true, or Windows development doesn’t have a future, or .NET full will be replaced with a 1:1 compatible stack on .NET core (not going to happen).

For once, and for all ISVs out there who have similar concerns as the ones I expressed (and I have only heard responses which were similar to what my thoughts were, no ISV expressed to me that they disagreed with what I said), get some consistency in your PR statements, Microsoft, as this is going nowhere.


Dumping code on Github alone will not be of much help. You have to actively build a community around it. This is the key. For this you need a shared vision in multiple project areas. Sooner this happens much the better otherwise the hype will fizzle out and people will loose interest.


Also keeping some key parts of the ecosystem closed source does not help the cause either because the Open Sourced version is a “crippled” version of the software.


I’m sorry that you are not getting the info you want.

You haven’t see a big statement from Microsoft since, as I suggested, the role and plan for the .NET Framework isn’t changing. We are shipping the .NET Framework 4.6 next year and there will be releases after that, all focused on building apps on Windows.

You do see a lot of excitement from my colleagues about .NET Core, calling it the future and otherwise. They are quite proud of what they are building and that its open source.

I think that the two statements can both be true at the same time. The .NET Framework remains focused on Windows apps, while .NET Core is the future of .NET app development on other operating systems and for some workloads on Windows, too.

We wanted to enable .NET on Linux and Mac. It is a non-starter to port the large .NET Framework for that purpose. We need to start with something smaller for that purpose. It’s a pure physics problem. We do hope that most library vendors and ISVs support .NET Core either sooner or later. We’re going to be running a program to that end in the new year.

I know its work to support .NET Core, but its also a new opportunity. That sounds like marketing spin, but it’s not. Mono has been on Linux for a long time, but .NET has not had a supported Linux and Mac story. If you wanted to get a lot of adoption of your library on Linux and Mac before, that would have been between hard and impossible. We’re now opening up that opportunity and making it straightforward. Many people are telling us that they are going to take advantage of this option for their apps.


@sirinath brings up that dumping code on GitHub isn’t a good option, but you need to build a community. We agree! We’re doing a lot on the corefx repo. It’s hard to call it inactive.

.NET Core isn’t ‘crippled’, but it’s also not complete. We’re going to continue to bring new libraries to .NET Core. Unlike the .NET Framework, which has a long ship cycle, we can ship a new .NET Core library at any time. We also hope that many community libraries get adopted as key libraries within the .NET Core ecosystem.

As I said in my reply to @FransBouma, we needed to start with a smaller body of code in order to support Linux and Mac. Once we have that all in place, it will be easier to add new libraries.


Agreed; I find it kind of funny to see people complain about “code dumping” and missing all the activity on corefx. I mean, over 400 commits to the repository in a little over 5 weeks isn’t something to take lightly, in my opinion. I also agree that Microsoft can, and should, focus on a stable codebase for Windows based machines that can be made compatible with .NET Core as it shows stability.


@sirinath Yes and no; yes in the sense that it’s not a complete user experience without the missing pieces and no in the sense that sometimes having part remain proprietary enables unusual options. A beautiful example is Mac OS X; with the exception of some low level drivers and the Aqua interface code, everything is available to build a functional Intel based Mac from source code and this has allowed unofficial Mac clones to be developed using official Mac OS installation media and community supported drivers for hardware combinations that Apple chose not to make.


How do you become competitive when looking at alternatives which does have UI and is portable.

Leaving aside UI perhaps some features like Solver, Core IDE, Workflow, Communication can be made open source and portable. Alternatives have solid offering in these areas through some are made by other parties.

Also there is much build code in couple of other bytecode formats now. How can this be leveraged in using and sharing code across different formats.

In short what is the strategy to be competitive and offer the best experience to developers and end users?


Biggest other two cross platform platforms are C++ and Java (IMO). C# (as well as Java) brings managed advantages like garbage collection for developers. C# over Java can be as simple as the fact that I personally will never put the Java Runtime on a machine unless it is a machine I either do not care about or can easily reset. It I has to many security holes. (Admittedly we really don’t know who secure the .NET Core Runtime is either.)

I think Microsoft expects you to use third-party things for Solver, Workflow, and Communication at least in the short term. They could even be other open source projects!

How does sharing byte code help? Confused

IMHO the advantages Microsoft is bring are

  • A very good and open language
  • A very good and well known runtime
  • A small set of common APIs
  • xcopy deploy
  • A huge open community of developers
  • iOS and Android potentially as well as other platforms

The biggest advantage is though that they can take all the knowledge from the big Full .NET Framework and brake it down into a core, simple framework that works everywhere and is open source.


A really good post by Mary Branscombe about why .NET Core matters: http://thenewstack.io/why-you-should-care-about-the-new-open-source-net-core/


I am really hoping that .net also adopts an Graal / Truffle like project (but better) which increase the scope and extensibility of CIL. This way you can support different IR formats directly on .net.

Any way most of the points I raised above is to see what the community response to the.

.NET Foundation Website | Blog | Projects | Code of Conduct