“.NET Core is the future”, but whose future is that?
It’s likely you’ve heard about Microsoft’s release of the .NET Core source code, their announcement of ASP.NET vNext and accompanying PR talk. I’d like to point to two great articles first which analyze these bits without being under the influence of some sort of cool-aid: “.NET Core: Hype vs. Reality” by Chris Nahr and “.NET Core The Details - Is It Enough?” by Mike James.
I don’t have a problem with the fact that the ASP.NET team wants to do something about the performance of ASP.NET today and the big pile of APIs they created during the past 12-13 years. However I do have a problem with the following:
“We think of .NET Core as not being specific to either .NET Native nor ASP.NET 5 – the BCL and the runtimes are general purpose and designed to be modular. As such, it forms the foundation for all future .NET verticals.”
The quote above is from Immo Landwerth’s post I linked above. The premise is very simple, yet has far reaching consequences: .NET core is the future of .NET. Search for ‘Future’ in the article and you’ll see more reference to this remark besides the aforementioned quote. Please pay extra attention to the last sentence: “As such, it forms the foundation for all future .NET verticals”. The article is written by a PM, a person who’s paid to write articles like this, so I can only assume what’s written there has been eyeballed by more than one person and can be assumed to be true.
The simple question that popped up in my mind when I read about ‘.NET core is the future’, is: “if .NET core is the future of all .NET stacks, what is going to happen with .NET full and the APIs in .NET full?”
Simple question, with a set of simple answers:
- Either .NET Core + new framework libs will get enough body and it will be simply called ‘.NET’ and what’s left is send off to bit heaven, so stuff that’s not ported to .NET core nor the new framework libs is simply ‘legacy’ and effectively dead.
- Or .NET Core + new framework libs will form a separate stack besides .NET full and will co-exist like there’s a stack for Store apps, for Phone etc.
Of course there’s also the possibility that .NET core will follow the faith of Dynamic Data, Webforms, WCF Ria Services and WCF Data Services, to name a few of the many dead and burned frameworks and features originating from the ASP.NET team, but let’s ignore that for a second.
For 3rd party developers like myself who provide class libraries and frameworks to be used in .NET apps, it’s crucial to know which one of the above answers will become reality: if .NET core + new framework libs is the future, sooner or later all 3rd party library developers have to port their code over and rule of thumb is: the sooner you do that, the better. If .NET core + new framework libs will form a separate stack, it’s an optional choice and therefore might not be a profitable one. After all the amount of people, time and money we can spend on porting code to ‘yet another platform/framework’, is rather limited if we compare it to a large corporation like Microsoft.
Porting a large framework to .NET Core, how high is the price to pay?
For my company, I develop an entity modeling system and O/R mapper for .NET: LLBLGen Pro. It’s a commercial toolkit that’s been on the market for over 12 years now, and I’ve seen my fair share of frameworks and systems come out of Microsoft which were positioned as essential for the .NET developer at that moment and crucial for the future. .NET Core is the base for ASP.NET vNext and positioned to be the future of .NET and applications on .NET Core / ASP.NET vNext will likely use data-access to use some sort of database. This means that my runtime (the LLBLGen Pro runtime framework, which is our ORM framework) should be present on .NET core.
Our runtime isn’t small, it spans over 500,000 lines of code and has a lot of functionality, not all of which is considered ‘modern’ but not all of us develop new software: most developers out there actually do maintenance work on software which will likely be used in production for years to come. This means that what’s provided as functionality today will be required tomorrow as well. Add to that that a lot of our users write desktop applications and our framework therefore has to work on .NET full no matter what. This has the side effect that what’s in our runtime will have to stay there for a long period of time, and porting it to .NET core will effectively mean: create a fork of it for a new runtime and maintain them in parallel.
I’ve done this before, for the Compact Framework, a limited .NET framework that ran on Windows Mobile and other limited devices, so I know what costs come with a port like this:
- research in what is not supported, which API acts differently what limitations there are and which quirks / bugs to stay away from or take into account
- features in the .NET framework aren’t there, so you have to work around these or provide your own implementation
- APIs are different or lack overloads so you have to create conditional compile blocks using #if
- because not everything is possible on a limited framework you have to cut features in your own framework, limiting usability
- less features or limited features in your own work mean you have to provide different documentation for these features to explain the differences
- a different platform requires additional tests to make sure what changed actually works
- additional maintenance costs for support, as issues only occurring with the additional framework require specific setups for reproducing the issue
- supporting a new platform isn’t for a week but for a long period of time as customers take a dependency on your work for a long period of time.
For an ISV or for an OSS team these issues have a severe impact: they take time to resolve and time has a cost: you can’t spend the time on something else. In short: it’s a serious investment.
I’m not afraid to do these kind of investments. In the past I’ve spent time on things like the following: (time is full time, just development work)
- Several months implementing DataSource controls for our runtime to be used in ASP.NET webforms. Dead: ASP.NET vNext doesn’t contain webforms support anymore. We still ship the DataSource controls though.
- Several months on adding support for Dynamic Data in our runtime. Dead. We don’t ship support for it anymore. Customers who want it can get the source if they want to from the website.
- Several months on adding support for WCF Ria Services in our runtime. Dead. We don’t ship support for it anymore. Customers who want it can get the source if they want to from the website.
- Several months on adding support for WCF Data Services in our runtime. Dead, as the future is in WebAPI, which is now merged into ASP.NET vNext. We still ship the library.
- Five months on adding support for Compact Framework. Dead. We don’t ship support for it anymore. Last version which did is from 2008.
- Two months on adding support for XML serialization. Dead. JSon is now what’s to be used instead. We still ship full xml serialization support with multiple formats.
- One month on adding support for Binary Serialization. Dead. JSon is now what’s to be used instead. We still ship full binary serialization support with optimized pipeline for fast and compact binary serialization of entity graphs.
- Several weeks on adding support for WCF services in our runtime. Dead, as the future is WebAPI, which is now merged into ASP.NET vNext. We still ship support for it.
- Several months on adding support for complex binding in Winforms and WPF: Still alive, but future is unclear (see below). We ship full support for it, including entity view classes.
- Almost a full year on adding support for Linq in our runtime. Still alive. This was a horrible year but in the end it was worth it.
- One month on adding a full async/await API to our runtime. Still alive. This was actually quite fun.
That’s just the runtime, and the changes required to ‘stay accurate’ according to Microsoft’s roadmap for .NET and what’s required to build a ‘modern’ application for .NET. As you can see, lots of time spend on stuff that’s considered ‘dead’ today but was very accurate at that moment or looked to be like it would become great soon.
One can also imagine that with the experience from the past, I’m a bit reluctant with respect to supporting new stuff nowadays, see it as a case of “fool me 10 times, shame on me”, or something like that. At the same time, things change, and if .NET core is the future for both server and desktop, we have to abandon the current .NET framework and its features anyway in the future, so moving is inevitable then. So what’s one more investment?
It’s not a simple investment
It’s not as simple as ‘one more investment, what harm can it do?’. The thing is that with a small ISV as we are, it’s crucial you spend your time on the things that matter: if things fail, it might be fatal to the company. This is different from a team within Microsoft which still get a paycheck after a failed project: they move on to the next project, or even get a chance to rewrite everything from scratch. So from the perspective of a Microsoft employee, it might look like something that might take a month or two and then you’re all set for ‘the future’, and if everything fails, well, we’ll all have a laugh and a beer and move on, right?
No.
When you write software for Microsoft platforms you’ll pick up a thing or two after a while and you’ll begin to see a pattern: Within Microsoft there are a lot of different teams, all trying to get the OK from upper management to keep doing what they’re doing. The numbers are so vast that it’s often the case teams are not really working together but actually against each other, even without knowing it, simply because they have their own agendas and goals and they’re only known within these teams. All these teams produce stuff, new technology to both gain users and the attention of upper management. Some of these technologies stick around and gain traction, others fail and die off. It can be that the decision of one team might affect the future of another, but that’s part of the game: in the end it will all sort out, perhaps both will stay, both will die, upper management will step in and demand the teams talk.
We 3rd party developers look at what’s produced by all these teams and hope to bet on the technologies that stick around. Chances are (see above) that you’re betting on a crippled horse with one lung, and your investment is rendered void after a period of time. It’s therefore crucial to know up front as much as possible before taking the plunge and hope for the best.
With the investment to support .NET Core and ASP.NET vNext in our runtime this isn’t different: I want to know up front why I am doing this, why this is the best investment for my time, time I can’t spend on new features for my customers. I don’t think that’s an unreasonable question.
“Sell me this framework”
So I want Microsoft to sell it to me. Not with PR bullshit and hype nonsense, but with arguments that actually mean something. I want them to sell me their vision of the future, why I have to make the investment they ask from me. “Sell me this pen”, says Jordan Belfort in ‘The Wolf of Wall Street’, while holding up a basic ballpoint pen. It’s from one the many brilliant scenes in that wonderful movie which shows how hard it actually is to sell something which seems trivial but isn’t. Microsoft acts with their communication about .NET core as the room full of sales people in the last scene of The Wolf of Wall Street but they have to act like Brad who picks up the pen and says “I want you to write your name on a napkin” to which Jordan replies “But I don’t have a pen”. “Exactly, buy one?”.
It comes down to which future they mean with ‘.NET Core is the future’, and whose future that is. Will my customers who write desktop applications using Winforms or WPF be part of that future? Or will ASP.NET users only be part of that future? It’s very vague and unclear and with that uncertain. There’s contradicting information provided both through official channels and through unofficial channels (e.g. email) that paints the picture of the Microsoft we have all known for many years: a group of teams all trying to do their best, providing value for what their team stands for and we outsiders have to make sense out of the often contradicting visions ourselves.
My wife said last night: “They don’t want us there, all they want is stuff they control themselves”. I fear she’s right (as always); I have never felt more unwelcome in the world of .NET as today.
Our future
So I decided to make my own future and see where that gets me. This means I’ll spend time I otherwise would spend on a .NET core port on new features for our customers and will take a ‘wait-and-see’-stance with .NET core. After all, our customers had and have confidence in what we provide is solid enough for their future and that’s what matters to me, not necessarily what’s best for Microsoft’s future.