Brace yourself, ASP.NET Core 1.0 is coming!

I recently did a tech talk and lab session at our latest internal conference here at Jayway and would like to share a summary of its context here in a blog post. A lot of exciting things are happening in the world of .NET and you can start here by getting an overview and go exploring yourself :-)

It first surfaced as ASP.NET vNext, it was formerly known as ASP.NET 5 but recently Microsoft announced that it would change it’s name to ASP.NET Core 1.0. The reason: it’s not “just another release” of the same framework, but rather a significant redesign of ASP.NET built from the ground up. It’s open source and available on Github and runs on the new .NET Core 1.0 framework which enables cross-platform runtimes for Mac OS X and Linux as well as Windows.

OK, but what is it?
It consists of many modular components which means minimal overhead. It’s no longer based on the infamous System.Web.dll but rather has become a bunch of NuGet packages where you can cherry-pick only the libraries that you actually need. ASP.NET Core 1.0 now has a unified and single aligned stack for Web UI and Web API  with integrated client-side development. It offers cloud-ready environment based configuration and ability to be hosted on both IIS or your own process. The new and lightweight HTTP request pipeline is very modular and gives the developer complete control!

The New .NET Ecosystem

1. the new .net eco system
On the left side we have the traditional ASP.NET 4.6 which is the feature complete and mature platform that is released today. It’s the full .NET stack we know and love but runs only on the .NET Framework 4.6 and Windows. To the right we have the new and exciting ASP.NET Core 1.0 which for now only includes MVC and web API but SignalR and Web Pages will follow ASAP. It can run on both the .NET Framework 4.6 as well as on the new .NET Core 1.0

.NET Core 1.0?
It’s a small optimized runtime that is very modular and portable. It include a subset of the traditional .NET Framework libraries and can be packaged and deployed together with your application . Then you could do side-by-side app hosting using different versions of .NET for example.

.NET Execution Environment (DNX)

A software development kit (SDK) and runtime environment which has everything needed to build and run .NET applications on Windows, Mac OS X and Linux. It provides a host process, CLR hosting logic and managed entry point discovery and can be interacted with through a command line tool. This is installed together with Visual Studio 2015 but can also be installed separately on your chosen platform.
2. dnx incremental compile

You can have multiple stand-alone installations of the DNX runtime and easily switch between which version to target by default. Applications can then run alongside each other with different versions of .NET and it also means that you don’t have to install the entire .NET framework on the server or computer in order to use it, you can simply ship it with your app itself.

MVC + Web API = MVC 6

As you may have heard ASP.NET MVC and ASP.NET Web API have become one and now uses the same libraries. We’ll see if Microsoft will change the naming and/or version numbers of this as well, but so far it’s going by MVC 6.

The new empty web application project structure:
3. empty web application
As you can see there have been made significant changes to the default empty web application project structure which consists of two folders: “Solution Items” with a global.json file and “src” which contains the web project itself. Just get a thorough overview:

global.json
The solution is defined by the contents such as which folders it includes and which SDK version the project will run. (VS 2015 still produces .sln files)

.xproj
The new project file, takes over from the old .csproj format.

Properties – launchSettings.json
Where we determine how we will be hosting and launching our web application either by opening the UI or the json file which reflect each other. Here we can change target framework among other settings.

References
This is where all server-side packages and references for the project reside and are determined by the dependencies in the project.json file. DNX 4.6 is the fully featured .NET framework. DNS Core 5.0 is the new modular framework. (Soon the name change to .NET Core 1.0 will be implemented here)

wwwroot
Folder for browsable static files, such as images, style sheets and JavaScript files served to client. No ‘razor’ goes here! As you can see we still have a web.config here.

Dependencies
For client side dependency management references. Tools such as Grunt, Gulp and NPM go here and brings a lot of web development possibilities into the world of .NET

project.json
File for managing project settings and nuget packages (dependencies). Simply add a reference to a package and save the file, Visual Studio will then automatically download the package and you are good to go!  – Don’t worry, it has IntelliSense ;-)

Startup.cs
This is the entry point into the application where the developer has complete control of the application configuration of the request pipeline and services.

The Request Pipeline

4. request pipeline
The request pipeline consists of a number of middleware which you might be familiar with from OWIN: They either return a response directly with or without doing some logic or they do something and send the request to the next middleware. There are many built in middleware such as MVC, serving static files, identity etc. but you can also add your own.

Services
5. services
ASP.NET Core 1.0 fundamentally encourages dependency injection and has its own simple built in Inversion of Control (IoC) container. In the ConfigureServices method located in the Startup class we hook up our common consumed services we want to inject into our application. It’s easy to switch out the default implementation with any other 3rd party IoC container such as Autofac.

Adding MVC to the Pipeline
6. add mvc to pipeline
To hook up MVC we first need to add the package into our dependencies in the project.json file.
7. add mvc to pipeline
Then we need to add the MVC middleware in the Configure method and the MVC services in the ConfigureService method. That’s it!

Diagnostics

8. diagnostics
We can get a nice detailed error page by referencing the Microsoft.AspNet.Diagnostics package in our dependencies and adding app.UseDeveloperExceptionPage(); in our Configure method.

Routing

Convention
9. convention routing
The same routing framework is used for MVC and Web Api and above we see three ways of syntax to register convention based routes. Looks familiar right?

Attribute
10. attribute routing
Attributes routing just became awesomer!
[controller] – matches controller name. So if you change name it still resolves correctly
[action] – matches action name. Also resolves correctly if the action name is changed.
{id} – matches a parameter
{id?} – matches an optional parameter
{id:int} – matches only an int parameter

Controllers

11. controllers
There’s no longer a special ApiController, just a Controller whose methods return a IActionResult which means you can return any kind of result type that inherits IActionResult. (simple objects, complex objects, HttpOkResult, JSON etc.)

Content Negotiation

The process of picking out the output format still applies the basic rules but with some new defaults. JSON is now the official default output, so no XML formatter is included by default. There’s a new property called RespectBrowserAcceptHeader which defaults to false. All of this is of course configurable in the service registration of the MVC options.
12. content negotiation

Filters and Attributes

Great news here: Filters and attributes now support constructor injection! – They can also be ordered with the IOrderedFilter interface. Usage still applies on controllers, methods or globally. The authentication filter has become a native part of the MVC pipeline so there’s no need for the dedicated filter anymore. Authorization however has renewed power and the good old Action, Result, Exception, Custom, etc. filters are still around. There are however two new filter types both of which inherits from iFilterFactory. All the above mentioned filters can be used as a service filter or type filter.

Service Filters
13. service filter
Filters that use the ServiceFilterAttribute need to be registered in the IoC container and will then be resolved with the IoC. This means you also have control over the lifetime scope. You can think of it as a provider of filters.

Type Filters
14 type filter
Typefilters don’t get resolved through the IoC container but uses ObjectFactory for instantiation so you can go right ahead and use your filters as a TypeFilterAttribute without any further ado.

Views

15. views
Again there’s exciting news in the views: dependency injection is also supported here! The service must of course be registered in your IoC container and then be injected into the view with @inject. You can now go ahead and use the methods in the injected service. If you take a closer look at the top of the image of the view file you’ll notice that there’s no long namespacing before the actual class or interface. This leads us to another cool thing which is the new _ViewImports.cshtml file.
16. viewsimport
Here we can register our namespaces that we want to use in the view. The _ViewImports file can be located in the Views folder directly and will have all namespaces available in all views or if it’s located inside a folder such as /Views/Home then the using statements will only work in the Home folder’s views.  – Just ignore the @addTagHelper statement for now, we’ll come to that in a little bit.

View Components

Similar to partial views but with more power! Great for rendering chunks of a view which may have some more complex logic behind it. Examples for view components could be a shopping cart, a login panel or dynamic navigation menus. You create one by deriving from ViewComponent, by decorating your class with the [ViewComponent] attribute or by convention ending your class name with ViewComponent.
17. view component class
It can be located anywhere in the project structure, I just added a folder called ViewComponents in the project root for good measure.
Next you add a Razor view with the UI code you want to render when calling the view component.
18. view component view
This file however MUST be located in a folder called Components. (Typically inside the Shared folder)
19. view component folder
You then invoke the View Component in any other Razor file and it will insert the code chunk from your View Component.
20. invoke view component

Tag Helpers: HTML all the things!

Enable server-side code to participate in creating and rendering HTML elements in Razor files. The brand new Tag Helpers that live in the “Microsoft.AspNet.Mvc.TagHelpers” package give us a more HTML-friendly development experience. A frontend developer who doesn’t use .NET will feel more at home looking at tag helpers rather than HTML Helpers.
21, tag helper html
The magic asp-for and asp-controller will generate the corresponding html into the DOM. You can use your view model properties more HTML fluent and the DOM will also generate attributes for your data annotations.
22. tag helper view model
So the input tag for the FirstName property
23. tag helper label
Generates:
24. tag helper generates dom
From:
25. tag helper generates dom from
Tag Helpers are Authored in C# and you will have IntelliSense for creating the HTML and razor markup in the view by adding the “Microsoft.AspNet.Tooling.Razor” package. You can target HTML elements based on element name, attribute name or parent tag.

NOTES:
I haven’t gotten the Microsoft.AspNet.Tooling.Razor package to actually show the IntelliSense though and I needed to restart Visual Studio every time I updated the _ViewImports.cshtml file..Minor details which I hope will be fixes in later releases :)

Roll your own Tag Helpers!

Create a class that derives from TagHelper
25.5 tag helper
Add the namespace in the _ViewImports.cshtml
26. addTagHelper viewimports
– Here I’m just adding all tag helpers in my MVC6_Example namespace. You can restrict this more if you like.

Insert your new custom tag helper into your Razor view file.
28. taghelper html
You can even pass in parameters by adding them as attributes to the HTML taghelper as shown above. The values are then automatically bound to the properties in the tag helper class and can then be used in the output. (Title and Body in this example)
27. taghelper example
It’s all convention based by default so the <example> tag will look for the ExampleTagHelper class but you can of course customize this instead of using convention.

Well, that’s all for now folks! You are welcome to check out my example application on github which we also used as a baseline for our exploration lab in our session and you are welcome to go for it as well. I hope you enjoyed the blog post and are just as excited as I am about the new era of .NET web development! Take care now :)

9 Comments

  1. gby

    Pretty good summary of Core 1.0, thanks!

  2. Paul Thiel

    Great summary, but I still see this as a solution chasing a problem.

    I find it ironic that Microsoft has kept the “ASP.NET” in the new name “ASP.NET Core 1.0″. Prior to that, Microsoft called their MVC product “ASP.NET MVC”. I have thought about this quite a bit and have some thoughts on the subject.

    In the beginning, Microsoft created classic ASP and it was (compared to the other technologies of the time) good. It was also immensely popular. Instead of old CGI applications, web development became easy.

    Over the course of a few years, however, the spaghetti-code nature of classic ASP proved difficult to scale. Microsoft realized this and took their tremendously successful Visual Basic windows development paradigm and extended it to the web with ASP.Net. This solved many of the spaghetti code issues of asp.net by separating the presentation (HTML) from code (Codebehind). Did junior developers still put application code in form events? Yes. Did experienced developers use this to separate their UI from their application logic? Yes.

    This happy state of affairs started 14 years ago and continues to this day for those who develop using web forms. The platform matured, robust 3rd party tool development took place, and there was much rejoicing.

    Alas, during this time, the religious purists noted that some inexperienced programmers put business logic in their codebehind. This was an affront against the separation of concerns god which could not be permitted to stand. Over the course of years, they created the Microsoft version of MVC. No more would programmers put any business logic in their presentation tier (unless it is embedded in the Razor pages making them look suspiciously like classic ASP spaghetti).

    Now, if the purists simply referred to MVC as Microsoft MVC, they knew it wouldn’t be adopted. They knew history, and saw the fate of Microsoft DNA, DCOM, Active X, .Net Remoting, etc…all technologies that were the “new way of doing things” that eventually were discarded as failed experiments. How to avoid this fate for MVC if it didn’t prove to be popular?

    The easy solution is to tag it to probably their most popular development product (ASP.Net) and call it Microsoft ASP.Net MVC. By blurring the lines, they would increase adoption and funnel people into this technology whether they like it or not. Developers would think “if I don’t go this route, I’ll get left behind.” At the same time, they would kill the evil web forms and the unclean codebehind. A two-for-one.

    A funny thing happened, though. People didn’t abandon web forms as the purists intended. The technology split people into two camps. The MVC camp and the webforms camp. The reason for this twofold. The first reason is that for most projects in a business environment, the people paying the bills don’t care what the technology is so long as it works and is stable. Like it or not, web forms are mature and tested. The second reason is that the MVC architecture requires a learning curve for limited benefit (other than pleasing the purists).

    Here’s where it gets really funny. Now we are moving to the new version of ASP.Net. It is not only the “next new thing,” but it is a “complete rewrite from the ground up.” They are pushing this even to the point of calling it Core 1.0. However, like the push to MVC they realize that many developers would prefer to work on a mature and tested platform unless the new platform provides significant advantages (like classic ASP provided over CGI or ASP.Net provided over classic ASP).

    Whatever shall we do? Of course! The new name is not Microsoft Core 1.0. It is Microsoft ASP.Net Core 1.0. Tag the .Net name to it because, let’s face it, developers like .Net. But at the same time, let’s strip it to the bone (and still not get it done on time). Let’s rip out web forms, VB.Net, etc…Wrap it in the ASP.Net wrapper and maybe we will fool those gullible developers again.

    Come on, Microsoft….Just call it ASP.Net for web forms development and Microsoft MVC for MVC development. Good developers will have skills in both, but not be forced into either.

    I’m glad that they are completely branching things even though they are keeping the misleading ASP.Net name. My prediction is that this branch will grow and end at the same dead-end as Active X, Microsoft DNA, etc.. in about 3-5 years. Some variation of web forms will be brought back and touted as a new feature…and the wheel continues to turn.

    Maybe I’m wrong, but I’ve been doing this a long time. Time will tell.

  3. abc@giftechnologies.com

    Brace yourself, ASP.NET Core 1.0 is coming!…..it’s ok .Don’t excite Microsoft.. Take Ur time to launch …but make sure them to don’t repeat their traditional method to apply or enforce a load of lots version of asp.net to developer and user …continuous version problem of Microsoft product is becoming headache and frustration of developer or end user…….

  4. smithcole

    Hi, Nice update on Asp.net Core 1.0. ASP.NET Core 1.0 now has a unified and single aligned stack for Web UI and Web API with integrated client-side development. I read it carefully. Here in this blog so much useful information available to know. I had a little bit idea about Asp.net when I hosted my business through Myasp.net. Thanks a lot for sharing with us.

  5. Marcus H

    Paul Thiel comment should be a article by itself. LIKE

Trackbacks for this post

  1. ASP.NET Core 1.0 is coming! | PipisCrew Official Homepage
  2. 17-02-2016 - Links, Links I love em all! - Magnus Udbjørg
  3. Les liens de la semaine – Édition #172 | French Coding
  4. Good Morning .NET Core – Mitrai's website staging

Leave a Reply