.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! Winking smile



  • The big difference here is most of those decisions/changes were made behind closed doors. The public only used to see the final result. As all their development is in the public now, you get to see a lot more of the changes that you mention in the article.

    With bringing it into the public, it means external developers are able to comment and shape how the product gets designed earlier in the cycle before it's finalised when it often may be too late. The opportunity in this is massive.

    Giving people the chance to have a play and develop in pre-release software is huge in terms of gaining experience in the new platform well before final release.

    While I believe RC1 was pre-emptive and they jumped the gun a little bit early on that one, the rest of the changes have to be seen as a looking glass into the process not an avenue for complaint about too many changes.

    I don't think they blew it and I hope the lesson isn't to close the development process off and only drop it a week before release.

  • I actually believe that Microsoft has been pretty transparent about changes and thought processes all along this ASP.NET Core development path. If you haven't yet, you should check out the weekly ASP.NET Community Standup, where they openly discuss what's going on and take on questions from the community. You can see access these standups and the archives via http://live.asp.net. And you can read the weekly transcripts along with the Q&A here: https://blogs.msdn.microsoft.com/webdev/tag/communitystandup/

  • Hi, Terri!
    Yes, yes, all that is true... I am also in the MVP mailing lists, where these topics are discussed. The thing was, there were lots of changes, and even when we thought things were getting stabilized (RC2), it turned out they weren't. That's all. :-)

  • Microsoft actually did a decent job of developing in the open and sharing early thoughts. The primary misstep on their part is calling any Core release "RC" before the API surface is considered complete. Labeling alpha code as RC just sets everyone's expectations wrong, with the current debacle as the not-so-pretty end result.

  • Hi, Morten!
    I do not disagree with you.

  • No, Microsoft blew it.

    I never saw such confusing management for a component so important. We were planning to use .NET Core to start development and since we got burned by Microsoft changes in the past, we decided to wait for BETA8 since it was carrying a GoLive promise. When RC1 introduced such important changes we already understood that things were going to get worse and that was confirmed by RC2. No way a company like Microsoft could do such things like introducing such big changes between last Beta and RC1 and then a full re-organization for RC2 and then promise more changes before RTM. That's just crazy.

    We have been forced to stop any development involving .NET Core before RTM and the OS nature of this project make us fear about more problems AFTER RTM. I wouldn't be surprised if important (albeit not so big as RC1 -> RC2) changes could be introduced after RTM. Result is .NET Core is a stay-away thing for us right now.

    So we had to get back to 4.6 and of course we have no way to plan cross-platform development using .NET if we stay on 4.6. A total mess.

  • I don't know how anyone can say that developing in the open is a good thing, given our experiences with .NET Core. Because the reality is external developers are being utterly ignored. The community have given clear feedback to the .NET team, and it's been ignored. Developers have offered to do the work to keep project.json alive, and have been ignored.

    This is NOT an Open Source project. It is a closed source project which publishes it's code.

    In such a situation, there is no excuse whatsoever for the backwards and forwards approach MS have taken. Major breaking changes after Release Candidate! My goodness, that's rubbish. Release Candidate means, short of defects, this is what release will look like.

    We invested time and money after .NET Core entered RC, for it all to be blown away. Utterly incompetent management. Worse yet, when we try and interrogate the thinking behind these decisions, well they won't let us. So not only closed-door decisions, but the very basis for these decisions is being kept secret.


  • Don't forget to take the (unofficial) survey on these changes:

  • Thanks, Sean!

  • You are comparing project.json (a file) with MSBuild (an exectubale) which doesn't make sense. I don't know how .NET Core projects were built, but I know it didn't have anything as flexible as MSBuild.

    MSBuild is basically a task runner, albeit a rather complex one. If they can take what's good about project.json (not the file but the workflow) like package dependencies instead of assembly references, and not explicitly having to include files in your project, then I think developers will largely embrace MSBuild (and the .csproj files).

    Just my 2c/

  • Hi, Mike!
    I am comparing project.json's build mechanism (there IS one, you know! :-)) with MSBuild.
    You are right, the "project.json build mechanism" isn't half as powerful - in fact, I never found mentions about its extensibility or capabilities.

Add a Comment

As it will appear on the website

Not displayed

Your website