Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

ASP.NET Core and .NET Core Overview


It’s been a long journey, but ASP.NET Core and .NET Core have been released as v1.0 RTM this week. Yay! Congratulations to the ASP.NET and .NET Core teams on building this massive framework and delivering what looks to be a solid 1.0 release.

A lot has changed since I wrote my first articles for ASP.NET ‘vNext’ in Code Magazine which were my first takes on the platform late in 2014. In this post I’m going to revisit the high level overview architecture of .NET Core and ASP.NET Core since so much has changed, to help you understand how the pieces fit together and what it means to develop on the new stack along with some personal thoughts on how I plan to approach all of this new tech in my own work.

It's been a long Wait

The last couple of years have been tough if you’ve been keeping up with Microsoft’s ever changing architectures for the new .NET and ASP.NET platforms. The .NET Core platform has gone through three major platform updates since this journey to reboot .NET started nearly 3 years ago, but now it finally seems that all of this churn is coming together in a much clearer vision of where .NET is headed. Even so not all of this unification and integration is going to come to fruition with the forthcoming RTM release, as more post RTM changes have already been announced. Rather, RTM for .NET Core and ASP.NET Core will be more of a stepping stone on a longer journey that continues to add new features as time goes on.

Drawing a line in the Sand

This initial release is about drawing a line in the sand and having a stable base on top of which additional frameworks and components - and updated features - can be built. It's also a stake to let people start using an official released version of these new tools. Microsoft is quite adamant in saying that although there will be a lot more changes post RTM, these changes are not going to be as drastic as some of the changes that we've seen as late as RC2. Instead future changes are supposed to light up new functionality that won't break backwards compatibility. More features available without breaking what's already there.

v1.0 has released with solid tooling infrastructure and a solid but ‘snapshot in time’ version of the .NET Core framework and a fully functional ASP.NET MVC application layer.

Of these major components the one most in flex is .NET Core, which is going to gain additional features to bring it closer to the full .NET framework after the RTM release. The v1.0 release is meant to bring a production ready and fully supported release of the .NET Core and ASP.NET Core systems so that early adopters have a solid, base production framework that is officially supported by Microsoft to deploy applications with.

But make no mistake - things are going to continue changing after RTM. But hopefully if we take Microsoft's word, the changes coming post RTM will be benign to existing code.

Building a Common .NET

With .NET Core and ASP.NET Core Microsoft is on a mission to build a unified .NET base library that provides a common baseline that all platforms that run .NET can take advantage of. Today there are a boatload of different .NET implementations and each has its own set of supported features. If you are a component developer today (pre-Core) it's very difficult to build libraries that can run on any number of the supported platforms.

Microsoft has been proposing to create a new .NET Standard, which is a 'standard' that defines a common base layer that a platform should support. They plan to implement this new .NET Standard across the runtimes Microsoft itself publishes. It's very likely that ultimately .NET Core - which is an implementation of .NET Standard - will figure heavily in this vision, with .NET Core providing a single implementation that can run on many platforms. We're already seeing that with support for .NET Core on Windows, Mac and Linux for the server version. But there are more OS's to worry about - Xamarins Mobile platforms running Mono, UWP Windows application, game development platforms and the desktop OS implementations that are currently served by Mono.

.NET Core is the vehicle to deliver on the .NET Standard and while it hasn't been officially stated, it's probably a safe bet that .NET Core will become the unifying runtime that eventually can span a server/desktop based runtime (what .NET Core does today), UWP Windows apps and what currently is Xamarins stack as well as the desktop OSs that Mono targets. This isn't all going to happen overnight and certainly not with this v1.0 RTM release, but with ASP.NET Core and .NET Core you're getting the clearest glimpse of what that world will look like today.

.NET and ASP.NET Core today

As of today (.NET Core/ASP.NET Core RC2) the landscape is still pretty fragemented:

.NET Platform Infrastructure today
slide slightly modified from previous Microsoft presentations from Scott Hunter and Jeff Fritz

On the bottom you have the core infrastructure of compilers, languages, runtime and tools that interact with them. Above that sit the base libraries, which is where most of the divergence that we are seeing today is centered on, due to the variety of different runtimes that all have different feature sets with some partial overlap. Above that sit the application frameworks like ASP.NET Core, Xamarin's mobile libraries and desktop Windows platforms like WPF, WinForm as well as full framework ASP.NET.

.NET Common Infrastructure

On the bottom of the stack you have the common infrastructure and tools that provide the base rock of the platform: The Roslyn Compiler platform, C#, VB.NET, F# and the runtime loaders and the new dotnet.exe based command line tools. This story is actually much better today than it was just a couple of years ago thanks to Roslyn's unifying influence that has made much easier to take advantage of the compiler as a platform. Alternate platforms can now much more easily use Microsoft compiler rather than reinventing the wheel including running the compiler on non-windows platforms. .NET Core on Mac and Linux uses Roslyn for example as do tools like Ominsharp.

The important thing about this base is that it provides a single set of tools to get started with .NET both as a developer and integrator. In this scenario .NET is installed from a single .NET SDK. Once the SDK is installed you can create a new project from the command line, compile it and run it all with a few very simple steps. As part of configuration you can specify which version of the .NET platform you want to target and the compilers will figure out how to build and run the proper version(s) using the correct runtimes.

You don’t need Visual Studio or install a host of other .NET SDKs – all that’s needed is the single .NET SDK that gets you everything you need to do it all. This common set of tools can be used to build, package, and deploy applications as I’ll show later in this article.

This may not seem very significant at first glance, but if you compare this to the process of getting started with full framework .NET today, this is a big step forward. Rather than installing the huge monster that is Visual Studio that gives you everything under the sun, or installing a host of disparate SDKs and support tools, a single reasonably sized SDK install gets you everything you need to build and run any kind of .NET application. You can get started with .NET within a few minutes of download and a short install.

To be clear – we’re not there yet as support for .NET Standard currently is limited to .NET Core applications at the moment, but if you’re building apps with ASP.NET Core or .NET Core you can see what this developer experience looks like. You can use command line tools, or you can use Visual Studio. You can use your favorite editor including editors on other platforms and use tools like Omnisharp to get a pretty good .NET dev experience outside of Visual Studio. Visual Studio still provides the richest environment for .NET development, but you can get the compiler and tools integration and a good chunk of the editor and Intellisense smarts in other environments now as well.

Posted in ASP.NET  ASP.NET Core  

The Voices of Reason


 

Andrew Lock
June 13, 2016

# re: ASP.NET Core and .NET Core Overview

Very nice overview Rick, I think you really captured the optimistic but cautious atmosphere surrounding the .NET Core ecosystem.

I'm interested to hear that you don't rate ASP.NET Core over the full .NET Framework. To me there's a lot of benefits to be had with this setup, as you called out. Given that most .NET developers right now will, by necessity, be Windows developers, and that they will likely already have the required infrastructure in place for building and deploying any apps built using this combination.

For these developers the cross platform and the reduced footprint don't really come in to it - the full framework is already installed on their servers anyway. The only thing you are losing out on is the improved performance in the infrastructure (which, is diminished anyway once you are behind IIS).

Don't get me wrong, I love the benefits .NET Core brings (being able to develop .NET on my Mac with VS Code is really awesome) but to me ASP.NET Core is a great net framework on it's own. Building on top of the full framework seems like the obvious way to start using it ASAP don't you think? That way, you get to work with the new ASP.NET framework, while your class libraries can remain pretty much untouched.

Rick Strahl
June 13, 2016

# re: ASP.NET Core and .NET Core Overview

@Andrew - Great points.

I thought that too about full framework development a while back but after playing around with that for a while you start to realize that once you start down that road you're not easily going to go to Core later. The framework differences are subtle but actually very annoying to track down later which is in the end going to be almost the same as migrating from a MVC5/WebAPI app.

If you plan on going full framework and staying there, then using the full framework would be a good choice, but as a migration path I think you're not improving things much compared to running on the existing optimized for Windows full framework of .NET.

Also there are some things that don't work well even with full .NET - like old style configuration. I haven't tried this recently but even if you used full .NET System.Configuration etc. wasn't working which meant that a lot of stuff wasn't working even with full framework without quite a bit of tweaking.

We'll see how this plays out. I think the biggest reason I'm not so excited about the full framework support is that things will change and change quickly once the ball gets rolling and it's pretty clear where Microsoft will put its effort. I'm thinking .NET 1.x to 2.0 here - v1 was pretty rough where v2 added many important features (generics for one) and rounded out the platform with all the missing stuff they couldn't get into v1. I think we're looking at a parallel scenario. Using full framework on this stack will later on feel like using COM Interop in .NET me thinks :-)

Andrew Lock
June 13, 2016

# re: ASP.NET Core and .NET Core Overview

@Rick - that's interesting you had issues with System.Configuration. It's not that surprising I guess given the complete overhaul to config in ASP.NET Core, but probably exemplifies what you're referring to in terms of not being a great migration route.

I completely agree with you in terms of where Microsoft is going to put it's effort in, and the potential for v2. Exciting times! :)

Dani Calbet
June 14, 2016

# re: ASP.NET Core and .NET Core Overview

To help with these migrations issues I think it would be useful to have something similar to MoMa (http://www.mono-project.com/docs/tools+libraries/tools/moma/) that helped to found .NET > Mono migration issues. Do you know if something like that exists?

Chris Marisic
June 14, 2016

# re: ASP.NET Core and .NET Core Overview

I develop on Windows. I host on Windows. I don't see a single purpose of .NET Core. It really looks like .NET became frozen in time for the past 2 years that if it wasn't for the release of C# 6, this would have been a glaring void.

Maybe summer of 2018 there will be a compelling story. There isn't today, there won't be tomorrow. And there won't be anytime soon except perhaps if Nano Server requires .NET Core because they won't allow full installs of .NET inside of a Nano Server (i'd be shocked, but it's possible)

jdan
June 15, 2016

# re: ASP.NET Core and .NET Core Overview

The biggest issue I have currently is that I have an ASP.NET Core 1 RC2 site built against multiple projects that are .NET 4.5, and it builds perfectly fine on one machine, but when downloaded from Visual Studio Online the exact same code doesn't build. It just doesn't. I doubt there is any inherent code that prefers a SurfacePro 4 over a SurfaceBook, so I simply have a code base that works on (at least) one machine, but not on (at least) one other machine.

And this is going to RTM in 2 weeks. Swell.

Rick Strahl
June 16, 2016

# re: ASP.NET Core and .NET Core Overview

@jdan - you might want to post your use case as an issue to the GitHub tooling repo. It's hard to tell what you're trying to do exactly, but I have several projects that use .NET 4.5 dependencies and they work fine when moving between machines and pulled from GitHub repos. There might be some configuration or dependency management that isn't right, but I encourage you to reach out to the team and see what they say if this is something that's breaking you.

jdan
June 17, 2016

# re: ASP.NET Core and .NET Core Overview

It was significantly convoluted how I 'fixed' it, but it is related to the /wrap folder that got created on the machine that worked (when the project/site was created back when it was ASP.NET 5 MVC 6, or whatever). This is/was (not clear from GitHub) how .csproj files could work with the .xproj file, but isn't part of the solution per se (kind of like the /packages folder) so it doesn't make it into Visual Studio Online.

I discovered if I removed that folder, the working machine no longer worked, with build errors similar to the non-working machine. So eventually, I just copied over the directory structure exactly, and that got the not working machine working.

It still isn't clear to me if this /wrap folder is going away entirely, and there appear to be a number of people who are similarly 'blocked' with this issue, so where this is all going, I'm not sure.

FWIW

Kev
June 22, 2016

# re: ASP.NET Core and .NET Core Overview

Great article, it tackles the reality of dot net today! I'd like to point out that I think the "full framework mixin" is actually more appealing than you may think.

I believe a lot of companies are interested cross-platform ASP.NET which DNX showed a lot of promise before RC2. Some reasons include being open source friendly, licensing costs, licensing complexity, operational complexity and tooling. All of these are debatable, and I wouldn’t criticise Azure or the efforts made to improve the DevOps tooling for Windows, but developers need the choice. In fairness to Microsoft they are embracing choice and open source but we need dot net to progress now or risk losing to other ecosystems.

In docker we are now running a hybrid dotnet-cli/SDK - mono environment so we can target net45x and use critical dependant third party libraries for our MVC6 application. It is a bit of a mess but works for now.

Cross platform asp net really needs Kestrel and I think the dotnet-cli could be pulled back on top of mono but maybe that is just me.

It is also unclear what the removal of project.json actually means to the dotnet-cli tooling. In a year’s time no one will care if it is json/xml/xaml/yaml but first class nuget support makes dot net feel like a modern framework in an opensource world.

Regardless of if you call it ASP.NET Core does anyone else think MVC6 + Kestrel + dotnet-cli needs a (mono?) option to run net45x/net46x in docker?

Rick Strahl
June 23, 2016

# re: ASP.NET Core and .NET Core Overview

@Kev - I think Microsoft has been pretty clear that *their* goal for NET45/46 is the full framework *Windows* version. I think the Mono story in this is questionable going forward. I also seriously question that we'll need a full framework version of .NET that is cross platform - the main features that differentiate full framework today are its Windows integration features which really are useless for xplat development anyway. As pointed out we're not there yet because current .NET Core is limited, but according to Microsoft's plans (whatever that will actually turn out to be) we should get much closer to full framework BCL with .NET Core by V2. If that's the case then what does Mono really buy you *unless* you're porting an old application that has specific dependencies on Windows specific features that were ported by Mono to work on Linux?

In time I think we'll see .NET Core be the platform that can handle what full framework does today in a cross platform manner with third party (or Microsoft) add-on libraries providing the additional holes that aren't covered. In the long term I don't see Mono as something that will be necessary. If anything I see Microsoft merging Mono and Core into something more comprehensive under the Core moniker.

But - all conjecture at this point really, but this is what seems the logical progression of what Microsoft has proposed to this point.

Mike
August 15, 2016

# re: ASP.NET Core and .NET Core Overview

I am loving where dotnet core is going - stripping back dotnet and making a clean lean version of it.

But whats up with the project files?
is MS backing up and reverting to csproj files or staying the xproj course? - is the framework all changing again come core 1.x ?
the dot net core message seems to be very confused.

The lack of basic support and functionality for what is branded as a 1.0 release is very disconcerting.
So many people are having problems getting core to work meqaningfully is very little solutions beingf offered.
The biggest of all of them is an example that works with asp dotnet core and dotnet 4.5 libraries.

This is a basic necesity for me (or anyone else?) to do anything more than glorified hello world.

*hopping down off my soap box*

that said if anyone can point me to an example of how to use asp dotnet core with libraries and same solution projects that does not require an ugly hack,.. Please please! ;)

All of these future plans are great but if noone uses it, it looses mindshare along with relevence. :(
 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017