We've gone live with our comparison website Compare Learning - which compares courses from different providers in Australia's education and training sector. Here's a short and sweet summary of what we've learned.

This is a more "agile", fluid Microsoft

And that comes with a trade off of stability. Wether this is a pro or a con depends on how conservative of change you are. We've hit bugs and we've hit regressions in 0.X releases.

We've also had excellent communication - be it in the form of GitHub issues or gitter/Slack chats. Long gone is the opaque Connect website for lodging bugs.

Stick with the Long Term Servicing (LTS) branch if you'd prefer a less bumpy ride, but it still might not be as smooth as you're used to.

Full Framework vs. .NET Core

One of the key features of ASP.NET Core (made all the more confusing by suffixing "Core" to everything) is it can run against not just the .NET Core framework but also the regular "full framework" (Mono too). This allows you to maintain your existing library (and Nuget) compatability. Anything that works against existing .NET you can continue to use if you target the regular full framework. Bear in mind that anything built for ASP.NET MVC5 specifically, whilst it will compile, it likely won't actually work.

Initially, we were targetting running the project against .Net Core, porting any necessary libraries as needed, however...

Sometimes you can't escape from [insert legacy technology here]

In our case, we needed to do some integration with a Government service and of course that means XML and SOAP. There is a .NET Core version of WCF available on github but it's very bare bones and didn't have all the bits we needed. That put running on .NET Core out to pasture for now and have us running against the good old full framework.

Entity Framework Core is still very young

And it feels a long way behind the rest of the rebooted parts. There are a lot of scenarios where queries are evaluated on the client, or Select N+1 situations are generated. In practice for this site, it hasn't been an issue. Our data is OK being stale so we're able to cache heavily - there are very few queries actually being run.

Of course, because you can run against the "full framework" you can still use EF6 or "your data access solution of choice".

ASP.NET Core (and friends) are much nicer to work with than than MVC5

From the way dependency injection is handled, to the logging, to the way options are configured - everything is so much less painful to setup and configure. This extends not just to ASP.NET but also to the other rebooted symbiotic parts of the stack. Identity is now much easier to extend, EF is a breeze to configure, etc. etc.

Precompiling your MVC views will make them case sensitive

Even on non-case sensitive platforms (like Windows). This leads to interesting scenarios whereby your code works fine when developing locally, but will fail once it hits production and the views are actually compiled. You should always treat it as if you're on a case sensitive system. This will make your code more portable to other platforms down the line as well.

Ordering of middleware is super important

And it's sometimes not at all obvious where something should sit in the middleware pipeline. Often your best bet here is to read the documentation of the middleware and document the way things need to be in your Startup function.

If you get this wrong, things might still work but not 100% how you intended. For example, if ApplicationInsights is not configured as the first middleware to run, it will still collect tracing information for your application, but it won't include information about middleware added to the pipeline before it.

Right now, the tooling scenario still isn't sorted

We're sticking with the doomed project.json until the final msbuild toolings makes its arrival with (I believe) VS 2017 RTM. There's been lots of consternation about the move back to msbuild and xml once you start to go behond anything trivial however with project.json it too becomes unweidly to use.

Should you use it yet?

Speaking broadly, yes. Right now, the biggest hurdle is likely to be the incomplete tooling. If you can hold off until that finalises you'll also have a much smoother time but even still, if you can put up with a few warts and rough edges I believe the benefits outweigh the issues.

Thanks to @dandy for help in editing/proofing.