Update January 27th:

As of January 26th Microsoft has changed course slightly, apparently based on feedback from various blog posts like this one and public discussions regarding the planned schedule for future RC and the RTM releases of .NET Core and ASP.NET Core. Previously the release date for RTM of ASP.NET Core was slated for end of Q1, but that has now moved to a more fluid schedule. The current status is TBD (to be determined) which means the release and RC dates are under review which we can assume to mean that the dates will be pushed out a bit further. I'm really glad to see this change, given the major changes that the platform is currently undergoing to support renaming to the new branding and the relative unstable nature of the platform up to even the current RC. This gives Microsoft more time to make these important changes, for testing (both for MS and those that try RC2) and getting this major, major V1 release of a new .NET and ASP.NET right on release rather than shipping on a fixed date. There's more info in yesterday's Community Standup where the announcement was made and some of the changes are discussed.

Yesterday Microsoft announced that what has so far been ASP.NET 5.0 has been renamed to ASP.NET Core 1.0. I'm really glad that Microsoft went this route and made it very clear that this version of ASP.NET is a totally new platform to build applications from and not just a small upgrade as prior upgrades from say ASP.NET 3 to 4 have been. ASP.NET Core is a brand new platform that has been rebuilt from the ground up – all the way to the core .NET platform libraries – to provide a leaner and cross platform implementation on what was ASP.NET. While there is a lot of feature compatibility with older versions, it does not have what you would call code compatibility meaning that you can't just run your old ASP.NET code in ASP.NET Core without a fair bit of change.

What's in a Name?

I really welcome the change of name and the renaming of packages and assemblies to match the new framework. It's a good change because we finally have a clear differentiator that makes it clear that this is a brand new version of ASP.NET (and .NET) that is very different from ASP.NET 4. The version number is also rewound to 1.0 for ASP.NET Core which is also nice touch as it indicates a fresh start, rather than the confusing naming that has plagued .NET versions upwards of .NET 3. Hopefully we'll see Semver versioning for ASP.NET Core and .NET Core going forward instead of the crazy version schemes that like .NET 3.5 running on framework 2 or version 4.5.x that in-place replaces version 4. According to Microsoft folks ASP.NET Core will also be search engine friendly and provide a differentiator from previous ASP.NET versions when searching for support content.

A bit late in the Game

So the new naming is great, but man, it is really late in the game to make such a major change that is affecting all the libraries in the framework. The name isn't just on the outside for product branding, but it's also affecting NuGet package names and the internal namespacing for libraries which affects just about all aspects of the framework. For existing applications this means you have to remove then add new packages and update each and every namespace to the framework libraries at a minimum. On top of that are numerous substantial core API changes. Updating any existing code pre-RC2 code will take a bit of effort to say the least.

Currently ASP.NET 5 (as the official pre-release version is still called) is on Release Candidate 1. RC1? Yes you read that right – Microsoft is completely changing the world of existing ASP.NET 5 applications by completely renaming the entire ecosystem. In addition all the command line tooling is also updated to use a whole new set of tools (from dnx tools to dotnet tools). The improved tooling is much easier to use – because it's a single command line utility – but wow what took so long given that this has been in discussion for a long time?

These types of major all encompassing changes are something that usually happens in the alpha or maybe the beta stage of a sane product development cycle. Alpha, Beta and RC have level of quality expectations and Microsoft simply did not apply the labels properly in the release cycle. To do a major refactoring 2 months before an announced ship date this seems kinda crazy and certainly doesn't warrant an RC2 moniker.

But then Microsoft has really bungled the entire release messaging that surrounds ASP.NET Core by setting expectations way too high for each of the stable Alpha, Beta and RC releases they have put out so far. By normal standards, none of these pre-release versions where anything close to what the name would have suggested. Given the current major change we are now seeing with this major rename, any other sane product would call the state of the product an Alpha (ie. break your world completely)!

Technical Kudos

To be fair, when it comes to the technical aspects of the ASP.NET Core architecture I continue to be very impressed how much the ASP.NET and Core CLR teams have been able to accomplish in the last year. The creation of .NET Core and ASP.NET Core are huge frameworks and they amount to a tremendous code footprint. It's very clear that ASP.NET Core is going to bring many major improvements to the ASP.NET Web stack, both in terms of the development process as well as the many new features that provide easier extensibility and easier over all development practices. In terms of implementation and even of the actual process of development of these frameworks I can't really find fault in the overall process that the ASP.NET and Core CLR teams have followed. With the frameworks being completely open source for all to see, it's easy to see what a monumental task these projects have been and what has been accomplished so far.

The actual development process and even the recent drastic changes are not out of line, were it not for the horrible messaging that has surrounded ASP.NET vNext from the very beginning. And it seems now that messaging is catching up with us.

What Message?

It's really been about mismanaged expectations!

What has been absolutely devastating is the messaging for the timetable that Microsoft has set for release of these products. From the very beginning it felt like the description was way off. When the first alphas and even the first betas shipped they were very volatile and you practically couldn't use them unless you used the daily feeds – which would promptly break something else. Back then even the betas felt like what Microsoft used to call an SDR preview release.

The later betas improved somewhat, but upgrading between betas was still an incredible pain as just about all the configuration and many apis changed for each release. Matching up NuGet packages in an upgrade was (and still is) a major task. Upgrading existing applications took hours and in a couple of cases nearly a full day even for a relatively small project. This is excaberated by the sheer number of packages that are now required by .NET Core many of which are so fine grained it's hard to reason what dependencies you might actually need to include.

Then came the first 'milestone' decision that wasn't communicated very well. When Visual Studio 2015 shipped last year, it wasn't clear until a scant two months before the release that ASP.NET 5 would not actually RTM at the same time. Anybody following the ASP.NET 5 development could probably tell that it wasn't going release at that time, but there was never really any announcement to the contrary and an almost implied air that all of the technology would ship all at once.  It wasn't until a community standup less than 2 months before RTM of that release, when it was mentioned in passing that 'Oh BTW we're only shipping Beta 5 with the release of VS 2015'. For months after the VS 2015 release a number of my customers were asking why we weren't starting to use (and upgrade to) ASP.NET 5 since it had been released.

When the Release Candidate rolled around you would expect some stability, but as soon as RC1 was released Microsoft announced that RC2 would break all the tooling and there would be some grand renaming that we are seeing now. This sort of thing does not go with an RC moniker – it's an alpha when you make that level of breaking changes. Think of the poor folks who were lulled in by Microsoft's 'Go Live' license that now have to go fix their applications for these name changes. Why in the world did Microsoft even allow a Go Live license, knowing full well these changes were coming down the pike? This is sending the wrong message and almost seems like it's meant to antagonize developers.

Now it's been made very clear that there will be RC2 (which is scheduled soon) and then RTM at the end of March (end of Q1) both with dates that aren't negotiable. I suspect RTM has to be done for the Build conference and who knows for what other commitments but apparently that date is set in stone.

I would much prefer that Microsoft gets version 1.0 right with an open release date of "it's done when it's done right",  rather than sticking to some arbitrary release date. While we can't rule out that the various teams get everything that needs to go into a 1.0 release finalized without rushing and cutting corners, I find that a pretty difficult task to accomplish given the current timeline. We can only hope that RTM hits all the high notes, because once RTM is done we are all going to have to live with whatever compromises had to be made for a long time.

RTM also has a certain level of expectations attached to it. People who will be trying out ASP.NET Core for the first time are going to have high expectations given all the hoopla that has been heaped on this new ASP.NET. If the product is buggy, or if it's difficult to get started with for the average developer, or if it's missing a major feature (data choices anybody?) that type of bad publicity can really end up hurting this new product in the long run. I think that it's very important that Microsoft hits a homerun with ASP.NET Core in order to keep developers on the .NET Platform and hopefully can attract some new blood into the .NET developer environment.

Mixed Messages

So for all the paying of lip service to OSS development, Microsoft is going to stick to a fixed release schedule come hell or high water. Scott Hanselman posted an announcement blog post for all of the new naming along with a description of these changes and reading between the lines you can tell that Microsoft is positioning ASP.NET Core 1.0 as a work in process and that the RTM release won't necessarily be a 'finished' product.

The message for some time has been that the 1.0 release won't be a final product. Development will continue post 1.0 RTM with many major features coming later, which makes sense. SignalR is one example of some significant tech that won't be in RTM but will ship later. That's not a bad thing since SignalR isn't a core feature but something that is bundled on top and so can be integrated independently. It IS however vitally important that the CORE framework and the CORE features of ASP.NET Core are solidly in place and the APIs are designed properly without cutting corners. While there may be later development for expansion, once RTM arrives the core APIs – just like the original .NET framework code from .NET 1.0 in 2001/2 – will stay with us for as long as the product exists.

You just don't want to screw up a V1 release of a core platform, because you end up having to live with it for as long as the platform lives. 

It's clear that development won't stop with RTM. But regardless I think it's absolutely critical to get RTM (or whatever Microsoft deems as the point of release) to be all that it's supposed to be. It's fine for high level features to be missing that can later be added (a la SignalR). But it's absolutely critical that the core framework features in .NET Core and the ASP.NET Core low level eco-system are rock solid and provide all of the API features you expect from a base platform on which to build on top of, right from the start. Once a core API exists it's very difficult or impossible to change it. So I really hope that Microsoft will think long and hard whether their RTM scheduling qualifies the code base to be truly ready to ship as an RTM release. A good feedback mechanism from those who'll end up using it is important for that, and that's what an RC is supposed to provide: feedback. And given the current schedule there's going to be preciously little time to provide that feedback.

As it stands with a fixed date RTM one big question is whether there will be enough time to get feedback and whether there will be enough people who'll actually try it in time. Especially given how hard it's been to keep up with these pre-releases. I'm not looking forward to upgrading even my simple sample application to RC2. I bet there are many others who have been burned by previous update cycles as well and are just holding off until Microsoft gives an official green light to a stable RTM release.

What ASP.NET vNext has meant for me

ASP.NET vNext has been a mixed bag for me. I was very excited when ASP.NET vNext was originally announced. The release promised to address many of the things that have started to become problematic with ASP.NET. And for the most part it looks like the ASP.NET team is actually delivering on those promises. The new framework is going to be much more lightweight, more pluggable, provide a host of useful new features, is cross-platform and more in line with modern developer practices.

I jumped in very early and played with the late Alphas and early betas. I experimented, and struggled with updates and  trying to understand the new architecture. I eventually got things to work and once I got the magic combinations together, the experience was indeed very nice. Coding was easy, the new features a delight to use and all was good. Until the next update rolled around. 

Getting things going was really painful in the beginning because there was very little documentation and lots of stuff was completely moved around or difficult to even discover. Fair enough, it was Alpha and that's to be expected. What I didn't expect was when Beta rolled around and things didn't get any easier. Each update brought major name and api changes and package conflicts because new versions had been renamed.

By this  time  I was hoping to write some articles about this new version. And I did in the Beta 3 timeframe for Code Magazine (and here). It's funny looking back at the articles and associated code. Almost nothing that I wrote in the getting started article applies anymore. It's like I was talking about a different product! That gives you an idea how much things have changed. Yet that was what was called Beta 3!

As part of the article I also built a sample application that I've been carrying forward through my vNext experiments. It's a small SPA application using using ASP.NET Core as an API backend. But it's insane how much effort went into trying to carry this simple application forward between the various upgrades. At some point during the last betas I gave up trying to keep up – the churn was just too much. But surely by the time the RC came out things must have mellowed out –  but no, same story. The upgrade from the last beta to RC was another big change. I suppose this can be forgiven as this is pre-release stuff and most people will not see that once RTM comes around, but I do wonder whether this will be any better once you update your RTM application to the next update release. We shall see.

As I mentioned before much of what I describe here is about the mismanaged expectations that were set by naming thing things Beta or RC. When you call something a beta or an RC I would expect a certain level of stability that ASP.NET 5/Core so far has never delivered.

In the meantime I've been holding off on a number of internal projects I've been wanting to get started. I wanted to use ASP.NET Core because it's internal stuff so it's a perfect place to experiment. I seriously regret that decision given that Microsoft has strung us along basically for 2 years with unstable betas which again was not what I would have expected. I'm still waiting for a jump off point where there's a stable place where the rug isn't continually pulled out from under me.

A lot of Unknowns

So to me ASP.NET Core is a mixed bag. On the one hand I'm excited to see all the new features and light weight framework with the potential for improved performance and lower footprint. There are many things that will make development easier. For MVC development TagHelpers and ViewComponents are awesome. For all apps the merged API and MVC engine is a big improvement. But at the same time I have huge trepidation about what the future of this OSS developed framework that is in constant flux will look like. I'm not sure that I trust Microsoft at this time to deliver RTM and keep the framework stable even after RTM so the pain points I've described above don't overwhelm in every version upgrade. So far the track record has not been good and that's a scary prospect having to deal with that with production applications in the future.

There are a lot of unknowns when it comes to ASP.NET Core and .NET Core. Because I haven't been able to really dig in and start building any substantial applications or even start porting over some of my common libraries it's hard to get a good feel for what the edge cases are with the new framework. There is lots to learn and lots to design differently.

Exactly what works and what doesn't isn't very easy to gauge up front. If you plan on using the .NET Core runtime, you'll be using a stripped down version of .NET that has the lowest common denominator needed to run on multiple platforms. That means a lot of stuff that was in full framework just won't be there. What that is exactly is not always so obvious. All platform specific Windows features are obviously not there, but there will be plenty of other stuff too. Many APIs have been truncated – many common overloads are missing from even very basic things, and features from individual APIs have gone missing. It's hard to get a good feel for this until you actually start working with  .NET Core and start pushing towards the edges of the framework which has been difficult for me so far.

We've all gotten very used to using a lot of third party NuGet packages/libraries – in .NET Core that probably won't be the case at least initially. Very few libraries have been ported to support .NET Core to date. That will change, but initially the number might be small. I know almost every application I build has a few specialty libraries. It might be a library to access a credit card processor, or a data access library for a NoSql engine, an HTML or Markdown parser etc. and chances are that code won't run on .NET core yet. Can you work around that? Maybe you can, maybe not…

For some time to come these are some issues that we'll have to deal with until the eco-system starts catching up. And yet that depends on how well ASP.NET Core/.NET Core are received in the first place. Which brings us back to the point I made earlier that it's crucial that V1 RTM is a solid release that hits all the high notes.

Clearly ASP.NET Core and .NET Core are a journey not a destination and we're at the very beginning of it. The beginning is rough as it usually is, until it finds its stride. I hope ASP.NET Core will find its stride soon and that the RTM release will be something to be proud of. We shall see…