ASP.NET Core 1.0 (formerly ASP.NET 5) represents the most significant release of ASP.NET since its initial release in 2002 and it’s projected to ship sometime this year. This post aims to provide a big picture overview of ASP.NET Core 1.0.
The most fundamental shift in ASP.NET Core 1.0 (formerly .NET Core 5) is that, by default, it targets the .NET Core 1.0 runtime. .NET Core is a small, optimized, and modular runtime that includes a subset of the .NET Framework. It has been developed in the open, is administered by a foundation, and is distributed with an open source license. Additionally, it is cross-platform and builds are available for Windows, Mac, Linux, and FreeBSD. This means, for the first time, Microsoft now fully supports building and deploying ASP.NET applications on non-Windows hosts. This is, obviously, a big shift and Microsoft has done an admirable job of explaining their motivation while reasserting their commitment to the current version of the .NET Framework that Campus Management Corp. currently uses.
ASP.NET Core 1.0, when targeting .NET Core 1.0, is also cross-platform, and that means that Microsoft has had to abandon the idea that Visual Studio is the only way ASP.NET applications will be built. Cross-platform command line tools have been shipped to drive the development process through project creation, scaffolding, migration, dependency management, build, testing, and even runtime execution. Visual Studio, of course, has been enhanced to support these tools with visual componentry, but Microsoft has also wisely shipped a cross-platform text editor in the form of Visual Studio Code as well.
Among the major changes coming to ASP.NET Core 1.0 is the unification of two similar but previously distinct object models–MVC and Web API. While the object models were extremely similar, they were actually two completely different code bases and that means that you previously did not have the capability to mix and match Web API functionality directly into a MVC controller (as is standard with other frameworks like Ruby on Rails or Django). This unification means that those building RESTful web applications can leverage the routing and controller logic to produce API experiences directly along side visual experiences.
This unification was possible because the whole of the ASP.NET Core 1.0 stack was rewritten. Conceptually, it remains mostly the same, but under the covers, it is quite different. Specifically, the introduction of a Dependency Injection (DI) framework allows the stack to be composed of both framework-supplied service implementations as well as custom service implementations. Most importantly, however, the developer has the ability to select only the services judged necessary for their specific application. This means an ASP.NET Core 1.0 application can run as efficiently as possible and need not pay the overhead of services it does not require while simultaneously providing developers with new tools to expand the capability of the core stack.
While the changes in ASP.NET Core 1.0 are almost exclusively sever-side they are coupled with the full scale promotion of the Single Page Application (SPA) paradigm in general, and Angular.js in particular. This is, of course, of little surprise, and completely consistent with our technology vision at Campus Management Corp. but it’s a nice confirmation that we’re all heading in the same direction. The impending release of Angular 2 further reinforces this impression, as Google has adopted Microsoft’s TypeScript language.
ASP.NET Core 1.0 promises to be an extremely compelling release of ASP.NET that extends the appeal of .NET outside of Microsoft’s walled garden and throws open the door to open source community at large. This puts ASP.NET Core 1.0 on par with other popular open source frameworks like Ruby on Rails and Django, but does so within the safely of the Microsoft ecosystem we know and love.