Making Sense Of The ASP.NET Core 2.0 Kerfuffle

The web has been going ballistic over a proposed ASP.NET Core change.

Exhibit A : https://github.com/aspnet/Home/issues/2022

ASP.NET Core was now going to run solely on…. .NET Core. Sounds confusing? Keep reading.

It’s been interesting to read reaction on message boards such as Reddit and HN. Mostly because people take the opportunity to lay the smack down on Microsoft without full understanding the situation. Certainly if you don’t use .NET Core on a daily basis, it just looks like Microsoft doing whatever it wants developers be damned.

But here’s the thing. I actually agree with Microsoft on this one to a certain degree. And I actually think their eventual decision to not press forward with the changes could actually hurt ASP.NET Core in the long run. This post is a bit of a riff off a Reddit comment I also made so it may be a bit over the place.

Let me explain.

There is currently 3 (main) ways to write a web application in the .NET ecosystem

  • ASP.NET Core
  • ASP.NET Full Framework
  • ASP.NET Core running on Full Framework

That last one is probably the eye brow raiser and the one that sounds the most “cobbled together”. And it’s actually the one that everyone is fighting over.

You see you can actually run ASP.NET Core on the full framework. You get all the benefits that the ASP.NET Core team gives you (Kestrel etc), but you still have the ability to use full framework libraries. Sounds like a win win right? Kinda.

The reason this works is because ASP.NET Core is written against .NET Standard. That means any classes/methods it calls will also be available in full framework. But it also limits the ability for ASP.NET Core to innovate. They are restricting their own platform to keep the ability of running on the full framework.

So how does the .NET standard work? There is another article on this site talking about the standard in general over here, but I’ll do my best to explain it in the context of the ASP.NET Core 2.0 debacle.

.NET Standard is essentially an agreement between the various .NET platforms (UWP, .NET Full Framework, .NET Core, Mono etc), that they will all implement the same functionality. Think of it like an interface where a class can write an implementation of a method however they like, but the important thing is that they implement it in the first place. The issue with the standard as it is today is that everyone has to move together. If the .NET Core team says “OK, we would like this new thing in the standard please”, they have to wait for agreement from another platform to put it into the standard and implement on their end too (Usually this is going to be from the full framework team).

The problem that the ASP.NET Core team is facing right now is that they have almost zero baggage and can move at an extreme pace. They are able to innovate and throw things into their platform as fast as a developer can code really. That’s why people are using ASP.NET Core running on full framework, because they are enjoying the performance improvements that ASP.NET Core offers. But for them to keep improving AND for ASP.NET Core to keep supporting the ability to run on full framework, they need the full framework to add things almost as fast so that new versions of the .NET Standard can be released.

That’s not happening.

And what that means is that if ASP.NET Core writes a new feature that utilizes something that is NOT in the .NET Standard at that point, they cannot actually release it until the .NET Framework catches up. The ASP.NET Core team has basically said that for them to keep moving at the same pace, they are going to have to make their libraries work on .NET Core only so that their only limitation to releasing new features is their own ability to write them.

To me that’s understandable. They probably need some sort of pathway for those that have been caught in the middle of this hybrid approach. But we can’t have a web framework that everyone loves for it’s ability to innovate be tied down by a legacy frameworks ability to do the same.

Microsoft has backtracked and said that they will continue supporting ASP.NET Core running on the full .NET Framework. I think it will be interesting a year from now to see how this pans out. Giving something like another years support seems look a good plan, but I don’t like the open ended support “we will see in a year” type approach.

What’s your thoughts?

6 thoughts on “Making Sense Of The ASP.NET Core 2.0 Kerfuffle”

  1. I agree completely. One of the principle motivations for the .NET Core project was its decoupling from Microsoft / Windows dependencies so they were able to innovate at a greater pace. The complaint was other frameworks aren’t tied down with enterprise requirements. And now .NET Core is … tied down with enterprise requirements. What a shower.

    Reply
  2. I attended the .net Q and A panel on Thursday at the build conference that included Scott Hunter and Damian Edwards. The impression I got there was that asp.net core 2 is still being targeted for the .net core 2 framework. The decision to support the full framework will be made at a later date and sounded like it would be the worst case scenario for them. They did say that they are committed to extending the support life cycle for asp.net core 1.1 on the full framework perhaps for 2-3 years. The basic message seems to be if you want to support the full framework stick with asp.net core 1.1

    Reply
  3. Innovation is of limited value if the community can’t use it, though.

    I think that the fundamental problem here is that the .NET team are looking outwards and focusing on competing with Go and Node.js, but .NET is *already* one of the largest programming ecosystems out there, and that community is largely enterprise developers, and almost entirely running on Windows.

    The most worrying things about this whole situation is that at best, folks at Microsoft are detached from the community, and at worst, the MS teams are at cross-purposes with their existing users. Key decisions are still happening behind closed doors in Redmond, and neither the Technical Steering Group at the .NET Foundation nor the existing MVP channels are working: it is astonishing that this whole thing had to play out on a GitHub thread on a commit that had already been made, days before a Preview release.

    Reply
    • If you look at the history of what’s now ASP .Net Core, it started as an attempt to provide a C#/.Net stack to compete with node.js, Go, RoR etc. Because they wanted to attract the cool kids doing all the cloud/mobile stuff before they lose the market completely. But there is a big problem with this: The Web crowd has established its own ecosystem based on the framework-of-the-week together with Angular(2) etc. You can find plenty of JS developers to hire. For this reason, there is only little adaption by the cool-kids.

      By far the most usage of ASP .Net Core is by Enterprises in need of a path forward from WCF or even .Net remoting towards REST style web-apis. I know many of such projects, they all have to move forward and can’t just break everything. They must provide a smooth transition. So they bring in a web-api in parallel to to their legacy interfaces. And their are locked to the full framework because of all the 3rd party libs they use.

      The Community dreams of providing the next-gen lean, cool Xplat web stack, but their users are in majority not the cool-kids, but the Enterprises. And the Enterprises are paying MSFTs bills. They buy the expensive VS Enterprise and volume Office and Windows licenses. And that’s why MFSTs management set the team back. It was a pitty to see how the ASP .Net core leads were sitting beside their senior manager at build, pulling their fingers nervously. You really could feel how uncomfortable they were. And the senior manager even stated loud and clear that’s not important what MFTSies write on github, in the opposite, its his word that counts solely. It was sad to see the team embarrassed in front of the whole build attendants.

      Reply
  4. I actually don’t agree with you man. The reason is very simple.

    Microsoft MUST support ASP.NET Core on full .net framework, because ASP.NET Core is an important product from Microsoft which must provide backward compatibility at all times. If they didn’t want to support full .NET Framework then ASP.NET Core should have never supported full .NET framework in the first place.

    But that’s reasonable, microsoft wanted to attract more people using ASP.NET Core, and majority of the .NET players were on the full framework.

    So, now what?, they should keep innovating in ASP.NET Core on both runtimes (.NET Core and full framework) even though it’s technically hard for them, but they have unlimited resources ..

    Thanks

    Reply

Leave a Comment