This post is no longer relevant as Visual Studio 2017 has seen a fair number of improvements over time.
ASP.NET Core MVC 2.0 Preview 2 again supports .NET, so YetaWF is again up and running with ASP.NET Core MVC (see the demo site).
But it wasn't exactly trivial to get it up and running. Opening the solution the first time took 20 minutes (not kidding). And the second time. And everytime thereafter. Until we discovered a workaround. But it's clearly a Visual Studio tooling bug (https://developercommunity.visualstudio.com/content/problem/75782/20-minutes-to-open-solution-vs-1530-preview-30-rep.html). There are numerous other reported issues by others, with similarly bad performance.
Visual Studio 15.3 Preview 4 seems generally sluggish, is unexplicably unresponsive at odd times, takes forever for the simplest tasks like moving, renaming files, and the list goes on. Even building the entire YetaWF solution takes an eternity (compared to Visual Studio 2015). Using Visual Studio 2017 (Preview) doesn't make for a pleasant experience.
Considering the MVC team seems to be winding down to RTM, Visual Studio 2017 appears to be blocking that, as it's seriously, ahem, not so good... You may think "Well yes, it's a preview". True, But the Visual Studio 2017 release that supports ASP.NET Core 1.1 has equally serious tooling issues. Visual Studio 2017 was rushed out the door and still hasn't been able to catch up.
There is however also some good news. YetaWF with ASP.NET Core is quite a bit more responsive than YetaWF with ASP.NET 4. Particularly views that haven't been precompiled yet appear to be available a bit faster. It generally "feels" quicker. Yes, even when actually measured. YetaWF with ASP.NET Core also has a smaller memory footprint, between 5-10%. Since YetaWF uses the same code base on either platform, any reduction in memory usage is directly attributable to ASP.NET Core (MVC). That's nothing to sneeze at. The extra performance is also welcomed.
In a few months, I'm sure all these tooling issues will be resolved, so maybe all the pain since starting to support ASP.NET Core will have been worth it. Especially as we're going to be able to slowly migrate to full ASP.NET Core without .NET 4.x. I do pity all large scale MVC (3-5) users who will experience large scale pain moving their sites to ASP.NET Core MVC 2.0. The smaller memory footprint and better performance doesn't readily translate into sufficient justification for the cost this conversion entails. Not everyone has the luxury of starting from scratch...