.NET Core Reloaded
OK, so here’s another post on .NET Core from a non-code perspective.
There has been recently lots of discussion about this all over the Internet!We are all well aware that .NET Core, which hasn’t been released yet (June 1st), has had some rough times. RC1 has been out for quite some time with a Go Live license, and RC2 just hit the streets a few weeks ago, substantially delayed according to the original schedule. The problem was, from RC1 to RC2 things have changed a lot, and are even going to change more with RTM.
We knew from day one that we wouldn’t have AppDomains, binary serialization, Remoting, sandboxing, Windows Forms, WPF, WCF and WWF, and most of us were cool about that. Also, having project.json instead of the old MSBuild seemed a step in the right direction – that is, the direction driven by Node.js and modern JavaScript technologies. Relying on Nuget for dependencies was also something that we were already doing, just not for the core assemblies. Having a smaller API surface than the one we were used to was harder to digest, but we could live with it.
But then it hit us: project.json is no more, and MSBuild is back, even if slightly crippled! Also, AppDomains will make a comeback, too… and so most of the “old” APIs, now hopefully sanitized for cross-platformity!
We recently had to put up with the horrible mess of KRE, DNU, DNX, DNVM just to end up with DOTNET. At some point we got a global service locator (something that the .NET Core team treats worse than the Devil itself) and them we lost it, as we did with property injection for ASP.NET MVC controllers (likewise), the ability to populate models from JSON or HTTP POSTs (also gone) and lots of namespace and type changes.
Let’s be clear: on the communication side, as well as in managing people’s expectations, Microsoft blew it. Even if in some aspects (IMO), they are going in the right direction, they got it all wrong. It seems that they haven’t given things enough thought, or have been experimenting with it for too long. Things don’t usually change so dramatically between RCs. How can software developers who have commercial products to release, are expected to deal with so many changes?
On the other hand, these were (are) RCs, meaning, pre-release versions, and nobody said that these would remain untouched. I don’t think these affect the global goal of .NET Core: having a modular, modern, cross-platform framework. I expect when it does come out, most problems will fade away. As we speak, it already runs in Linux Docker containers, and we can debug it from Visual Studio – and Visual Studio Code. I kind of like going back to MSBuild, because it is so much more powerful than project.json. Bringing back AppDomains only widens our horizons, not the opposite. And I really, really like the stuff they’ve been doing in ASP.NET MVC Core.
.NET Core will give us more flexibility, in the sense that we aren’t limited in using Windows as the deployment target. For myself, it’s going to be about the capability to deploy Linux VMs as Docker containers, but this time running .NET, and not just Node.js. I don’t see myself moving to full-time Linux or Mac development, but Visual Sudio Code and Project Rider do seem to make it possible. None of this was affected by all the shifts and changes that occurred in the .NET Core gestation. Only confidence in the Microsoft .NET Core team was affected, to some level.
So, in retrospective, I think Microsoft has learned a lesson. Give stuff more thought before announcing it or making it public (I know, I know, .NET Core is open source, so the repo is publicly visible), hear from the community before making changes and not after them, and stick to your decisions! 