Engage on Facebook Engage on Twitter Engage on LinkedIn Engage on GitHub

The New and Improved .Net Framework and ASP.NET vNext

By Rich Campbell

Over here at the Engage Headquarters, we recently have been excitedly discussing ASP.NET vNext, or as it is now called, ASP.NET 5 and the changes that will follow. This is a fair warning before reading on, this article is from more of a technical perspective than anything else.

Why Change?

This is a complex question that to fully understand, we need to have a deeper knowledge of the history of ASP.NET. ASP.NET v1.0 was released in January, 2002 by Microsoft to allow for a dynamic way to produce web pages. When it first came out, it was a very lean and fast framework built on CLR. As the years went on, many new features and functionality have been added to the framework to give developers the tools they need to evolve with the changing trends in programming.

MVC was released in 2009. Web API was released in 2012. Along with many other things before, in between, and since. These two features specifically though, have very similar functionality. While MVC is used to return both data and views, and Web API is just used to return data, they are very similar and shouldn’t be completely separate entities inside of the .Net code base… but they are. This is because when MVC was released, it took a dependency on System.Web, which is dependent on IIS, because we weren’t thinking about self-hosting applications in 2009. A few years later, in 2012, our mindset had changed. Web API needed to be more modular to adapt with the times and allow for hosting outside of IIS, so it was written to not use System.Web at all so that we could self-host our controllers. The rewrite of ASP.NET allows the combination of these development models, along with many other development models to give us a leaner code base with less overhead.

Another note is, currently, .Net is a one size fits all framework. You have to bring in everything that .Net has on the server. This creates a lot of overhead for stuff that you don’t need. As an example, most applications don’t use SOAP operations anymore, but when ASP.NET first came out, SOAP services were popular, and so you are loading the ability to perform these SOAP operations on the server, even though they are never used. With vNext, we will now be able to control what we use in our applications and only load what is required. This helps to reduce unnecessary overhead.

Extending on the modularity of the new ASP.NET framework, there are times when you have numerous applications running on the same server. Up till now, they all had to use the same runtime version, 4, 4.5, 3.5 etc., whatever that may be. With the new rewrite of ASP.NET, they have now allowed the runtime to be packaged completely with the application. The runtime will no longer be stored at the server level, but rather at the application level, which allows us to have applications running different versions of .NET all on the same server. This is all done through NuGet, which is now a first class citizen, which we will talk about a little later.

Another drastic change in the framework is that ASP.NET applications currently cannot be hosted on anything but IIS, but as I am sure you have heard, vNext is going with a new completely modular approach that allows you to control the request pipeline and can still be hosted on IIS, but can also be self-hosted or use another web server altogether. This means that you could theoretically host it anywhere. This includes hosting it on a thumb drive. I actually was watching a presentation in preparation of this where someone did just that. It was actually shockingly simple. This would have been next to impossible to implement without a complete rewrite on the ASP.NET code base. This also, grants us the ability to host .NET applications on Linux and Mac machines as well.

Another change in trends for computing is the idea of the cloud. As we know, cloud computing has taken the computer world by storm. While ASP.NET handles cloud computing fairly well, it wasn’t specifically built for handling computing on the cloud. To get it to work correctly, there is a lot of workarounds that are happening that you don’t see. It takes the configuration in the Web.config of your application and essentially mangles it with the values it needs. With ASP.NET, there is no more Web.config. The configuration system is configurable, storing your settings as JSON by default, and is much easier to integrate with the cloud for less overhead and better performance. They even have an all new cloud optimized framework, which is a condensed version of the full framework built specifically for running on the cloud.

How has it changed?

The first change that should be discussed is the removal of APIs from the framework. System.Web is completely gone now. As I have mentioned, currently with .NET, we have a lot of bloat. Right now, each HttpContext request costs around 30k of memory. The removal of these bloated APIs allow for reducing overhead to around 2k per request. This is going to affect us greatly because we may not be able to use all of the HttpContext items that we are used to. We may be able to bring in optional packages that will allow us to fill in the gaps with these APIs, but we also may need to write our code in a different way to get this to work. This is only a raindrop in a pool of API removals. I think we will have to wait and see how many APIs are removed before it is truly known the impact it will have upon us.

Another change that will affect how we work is adding in the Roslyn compiler. Roslyn is a compiler that now runs in a more efficient way by running in memory on an as-needed basis. This change will be one of the biggest time savers in the new framework. We won’t have the long process of making a small change and having to build and regenerate the binaries just to view that change. We now just have to save and view our changes. I have worked on projects that take a few minutes to build, so constantly having to rebuild for small changes would give me quite a bit of time to kill in between. I will no longer have to switch between tasks and get sidetracked after making a small change. Your changes will work instantaneously. Roslyn, along with the rest of ASP.NET vNext, is open source and can be found on GitHub. There is a link to it at the bottom of this article.

The next change in the new framework that will affect developers greatly is NuGet becoming a first class citizen. We will no longer have random references floating around that the project references and includes. Everything referenced will be handled through NuGet now. This is good because handling dependencies can be hard, but now dependencies will be automatically handled for us. As an example, when I first started on a client’s project, I took a copy of another developer’s local site and restored it on my machine. When I did this, the site was not working because of a referenced binary having dependencies on other binaries that I didn’t have. The other developer wasn’t seeing the problem because he had those binaries in his GAC, and they must have been in the GAC on the server as well. I had to have another developer send me those binaries from his GAC so that I could put them in my application bin. This will no longer happen, because all dependencies will automatically be brought with the project and will restored upon build.

Along with NuGet, Dependency Injection is now a first class citizen in ASP.NET. For those of you who do not know what dependency injection is, it is a software design pattern that implements inversion of control for resolving dependencies. Dependency injection means giving an object its instance variables. Really. That's it at a very high level, we could probably give a whole talk on dependency injection, so I will just leave it at this for this post.

Tag helpers are another new change in ASP.NET vNext that have been introduced to replace an attribute name and is mapped directly to a C# property and automatically injected. Tag helpers are basically syntactic sugar that is used to make readability better. I think the best way to describe tag helpers is by showing an example.

Before tag helpers, our Razor scripts would look something like this:

@using System.Security.Principal
@if (User.Identity.IsAuthenticated)
{
    using (Html.BeginForm("LogOff", "Account", FormMethod.Post, new { id = "logoutForm", @class = "navbar-right" }))
    {
        @Html.AntiForgeryToken()
        <ul class="nav navbar-nav navbar-right">
            <li>@Html.ActionLink("Hello " + User.Identity.GetUserName() + "!", "Manage", "Account", routeValues: null, htmlAttributes: new { title = "Manage" })</li>
            <li><a href="javascript:document.getElementById('logoutForm').submit()">Log off</a></li>
        </ul>
    }
}
else
{
    <ul class="nav navbar-nav navbar-right">
        <li>@Html.ActionLink("Register", "Register", "Account", routeValues: null, htmlAttributes: new { id = "registerLink" })</li>
        <li>@Html.ActionLink("Log in", "Login", "Account", routeValues: null, htmlAttributes: new { id = "loginLink" })</li>
    </ul>
}

As you can see, there is a lot of functionality in it that you would be missing if you didn’t know C#. With tag helpers the same code above looks like:

@using System.Security.Principal
@if (User.Identity.IsAuthenticated)
{
    <form method="post" controller="Account" action="LogOff" id="logoutForm" class="navbar-right">
        <ul class="nav navbar-nav navbar-right">
            <li>
                <a controller="Account" action="Manage" title="Manage">Hello @User.Identity.GetUserName()!</a>
            </li>
            <li>
                <a href="javascript:document.getElementById('logoutForm').submit()">Log off</a>
            </li>
        </ul>
    </form>
}
else
{
    <ul class="nav navbar-nav navbar-right">
        <li><a id="registerLink" controller="Account" action="Register">Register</a></li>
        <li><a id="loginLink" controller="Account" action="Login">Log in</a></li>
    </ul>
}

This is much more concise and readable markup that is doing the same thing by using the attributes on the html element.

Another constraint that we can finally remove in ASP.NET vNext is the constraint of having to develop on a Windows machine and having to use Visual Studio to build and debug our code. We now will have the ability to develop applications in any server environment using any text editor that we choose. We can now use Sublime Text to edit our C# code. This is a huge step in the right direction for modularity. While I enjoy working inside of Visual Studio, I hate having to wait a few minutes for it to start up when I am just trying to make a quick change to a single file.

Another change coming in vNext that will greatly affect us, at Engage, is the death of Web Forms. Web Forms is what we use today in most of our applications because of the constraints of developing DNN modules. This change is sure to affect us greatly, as our development strategy and application architecture will have to change to accommodate the changing technologies. I’m not sure what exactly this will look like now, but I’m assuming MVC and SPA modules will be the main development focus inside of DNN neXt.

I am really excited about all of these changes in the not so distant future. I look forward to learning and adapting with the new framework as we go. It will be a really exciting time for .Net developers in the coming months.

Resources

Planning a DNN upgrade? Download our guide