May 13, 2017

.NET Core is Probably Fine

So, BUILD 2017 has come and gone and lots of new exciting updates have been announced or made available for preview in .NET-land, most notably the preview release of .NET Core 2.0.

TL;DR; 2022

However, the issue that grabbed the attention of many of the developers in the .NET OSS space was this small change that snuck its way into ASP.NET Core 2.0 preview , wherein the ASP.NET team dropped support for NETFX (the full .NET framework) without any discussion beforehand. That thread is massive - sitting at well over 500 comments at the time of writing this, but the issue was resolved and clarified during a panel discussion with the ASP.NET leadership at BUILD this week and well as an earlier, official blog post:

This preview version of ASP.NET Core 2.0 ships with support for the .NET Core 2.0 SDK only. Our goal is to ship ASP.NET Core 2.0 on .NET Standard 2.0 so applications can run on .NET Core, Mono and .NET Framework.

As the team was working through the last of their issues before Build, it was uncovered that the preview of ASP.NET Core 2.0 utilized API’s that were outside of .NET Standard 2.0, preventing it from running on .NET Framework.

One issue that remains a bit of a sticking point for many of the developers on that thread and elsewhere though: if this was simply a miscommunication between the ASP.NET team and its users, why was the entire ASP.NET Core team so insistent that dropping support for NETFX was a necessary and just thing for ASP.NET Core 2.0 and beyond? Take a look at this comment from Scott Hanselman:

.NET Core is side by side and it’s moving fast. It’s WAY faster than .NET (Full) Framework can move which is good. By building ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means stuff can be built faster than NetFx or even Netstandard.

NetCore > Net Standard > NetFx when it comes to development speed and innovation.

Point is, if you are doing new work, netstandard20. If you have older net461+ libraries, MOST of those can be referenced under ASP.NET Core 2.0.

And lastly:

What we need from you all is a clear list/understanding of WHY you think you need ASP.NET Core 2.0 to run on net461+. Be specific so we can close those gaps and let everyone be successful.

It’s readily apparent from the ASP.NET Core team’s comments, to anyone with even a most basic command of the English language, that there was a plan to drop ASP.NET Core support for NETFX long-term in order to move faster on implementing features such as HTTP 2.0 support and so forth.

Therefore, doesn’t that contradict the official statement put out by the ASP.NET Core leadership, that the plan all along was to support NETFX and Mono and .NET Core simultaneously?

Upon digesting the events of last week for a few days, my conclusion is: no, it doesn’t.

What happened, IMHO, is there was a breakdown in communication between the team implementing ASP.NET Core and its product management. The result being a raging tire fire of a Github thread and a lot of upset users worried that their investment into .NET Standard and ASP.NET Core was about to become technical debt with no officially supported upgrade path. The official announcement was the result of product management stepping back in and getting the implementation team to align with the interests of the end-users.

Credit Where It’s Due

There’s some corners of the .NET community that wish the ASP.NET Core team stuck with its plan to drop NETFX support and send off ASP.NET Core on a pure .NET Core-only path in the name of faster innovation and faster applications. Unfortunately, that is clearly not the right call, hence why it was reversed by ASP.NET leadership.

I explained the issue in detail in my comment on the Github thread:

Try telling the ASP.NET / NETFX developers who build finance applications that move hundreds of millions of dollars a day, healthcare applications that deliver treatment to patients, services that manage energy production and consumption, and real-time safety monitoring for transportation systems all over the world to throw away their “legacy” code and start over. These developers are the reason why the ASP.NET team is employed in the first place - they buy the MSDN licenses, the big Azure enterprise agreements, the giant Office subscriptions, and the large SQL Server deployments that fund the creation, development, and maintenance of these tools to begin with.

What these folks are saying on the thread is “in no way, shape, or form could I sell a change of this magnitude to my management for so little benefit.” Having a 10x improvement in request-per-second throughput is not a good tradeoff compared to the suspension of business activity it would require to replatform so abruptly, especially with the gaps in the two technologies being what they are today.

There’s clearly a divide between two camps of people here: folks who want a greenfield future not constrained by .NET’s past and folks who would like to be able to have that, but recognize that it’s not economically feasible for them right now. The latter group already won the argument, and rightfully so, because they’re the users who make up the biggest consumers of the .NET platform. The folks who are independent operators who can afford to adopt new technologies quickly are going to be stuck in the same boat as us, but that’s the price they pay in exchange for free editions of Visual Studio, Code, great OSS tools from MSFT, et al.

The ASP.NET Core team’s engineers want to build the best product possible and it shows in the level of effort and attention they put into their work, all of which is visible on Github.

But even the most talented developers can be guilty of tunnel-vision: focusing too narrowly on a small set of features to the detriment of the big picture.

It’s my belief that the ASP.NET team was guilty of that: focusing too heavily on improving performance and turn-around time at the expense of platform stability and availability for its users. It’s a good intention: the Internet is a rapidly evolving platform with lots of new features and lots of new demands from end-users. Being a cornerstone technology for supporting that like ASP.NET is a demanding task and engineering choices that make the technology better and faster are strategically sound. But, as is the case here, not when those choices make the end-users distrustful and suspicious about the long-term viability of the platform.

The good news though: the OSS system worked. A really impactful change was made with insufficient communication, discovered by users, reported to the maintainers, effective communication was restored, and the outcome was reversed to the benefit of the users.

I’ve been critical, to put it mildly, in the past of how the .NET Core effort has been managed and how the team developing it has managed expectations with end-users. So having been a vocal critic in the past, let me say that the ASP.NET Core team deserves credit where it’s due here: they did the right thing and fixed the problem for end-users before it became a production issue.

This, to me, indicates that the .NET Core team has a much clearer direction and mission than they’ve had historically and that they were quick to reign in a project that had gone offscript. That’s what product management is supposed to do. So now we know there’s a clear direction to the .NET Standard / Core effort as a whole, what it is, and what to do if we see something that deviates from it. This is good!

That being said, it’s still worth asking the question “why was this an issue in the first place?” It’s not a big deal and the ASP.NET Core team should be comfortable explaining the reason for the initial proposal and the change.

State of .NET Core

.NET users and Microsoft have both struggled with the new(ish) open source way development tools are built and shipped at Microsoft, especially when it comes to realigning our expectations around how those products are made and delivered.

We’re used to Microsoft shipping technology that “just works” and Microsoft is used to having the freedom to develop that their own way without much external input during the development process. But we’re in a new world now where Microsoft might throw out some ideas that represent big changes in the platform just to see what happens, and they’re in a new world where we might grab our Internet pitchforks and let them know that those changes suck.

Nowhere is this better exemplified than in .NET Core, which is meant to be a total open source, cross-platform re-imaging of .NET from the ground up. It presents a radical new path to the platform and a lot of carefully considered tradeoffs between breaking with the past and supporting it in order to make the .NET Core tent as big as possible. Given the scope of the effort, it’s inevitable that there will be lots of opinions and stakeholders voicing them loudly.

In my end of the .NET universe, we’re working at a fever pitch pace on adopting .NET Standard. NBench v1.0, released last month, fully supports .NET Standard and includes a .NET Core runner. And Akka.NET is currently undergoing a major shift to release .NET Standard support in its v1.3 release; all pull requests must target the v1.3 branch and support netstandard1.6 tooling in order to be merged going forward.

I wouldn’t bother committing my time and my company’s resources to either of these efforts right now if I wasn’t sold on the benefits of running on .NET Core / .NET Standard as a viable option. This time last year, I wasn’t sold at all on .NET Core or .NET Standard; “needs more time to bake first” is the comment I gave to an end-user at the time. That’s a positive change and I owe that largely to the improvements in the tooling and in the .NET Core ecosystem as a whole.

I’m sold on .NET Core and .NET Standard, but both of those platforms have to support a big tent of users. From small startups and independent consultants to massive Fortune 100 companies, we’re all in in this together. So we should keep on and support Microsoft as they shoulder the burden of shoring up the bedrock of .NET; and we should also hold them accountable when they go down a blind alley or flirt with “Python3-ing” .NET Core.

This 2022 incident gives me confidence that the team has done a good job listening to its users and developing a good working relationship with its users as both an OSS community AND customers. That’s a sign of growth and maturity which should be lauded and supported.

.NET is a fantastic community that I’ve been a part of for 15 years and I’m looking forward to being part of it for 15 more. And part of that future is going to include learning how to interpret the new “open source-friendly” Microsoft.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..