.NET Core 1.0–The Framework we need

Are you old enough to remember the release of ASP.NET? I unfortunately am, I distinctly recollect it presenting a straightforward abstraction over the existing Classic ASP programming model. It took me a few years to realize, however, that the abstraction layer was designed to hide the truth of traditional web development from novices like me, and that this was not necessarily positive. But it genuinely assisted the transition to the web for those of us who were more comfortable in the event driven Windows desktop world.

How about the ASP.NET Page execution cycle diagrams? Just wow! Our world was ruled by HttpModules and HttpHandlers, and web services could only to be constructed in ASMX files, it worked but it represent a kind of cynical compromise for wed development standards.

From my perspective until we got genuine MVC integration we were living and working in a framework that was designed by Microsoft for Microsoft. Now, for the first time in a long time, I am confident that the changes upon us are developed on the idea of limited compromise.We have gone from being inexorably tied to the IIS and Windows to now punching holes in the space-time continuum and popping up into self-host scenarios, and even onto Mac and Linux platforms, with the notable release ASP.NET CORE 1.0.

The framework we need

So what is .NET Core?

• Light-weight and modular HTTP request pipeline
• Single web stack for Web UI and Web APIs
• Built on .NET Core
• Ships via NuGet packages
• Build and run ASP.NET apps cross-platform on Windows, Mac and Linux

The .NET Core command line (CLI previously DNX) is the runtime environment (and SDK) that has everything you need to build and run .NET applications for Windows, Mac and Linux.  Instructions for the installation of SDK can be found here. To create a new project, it is as simple as this:

• Open your command window
• Create a new folder and navigate to it
• dotnet new creates a new project
• dotnet restore brings down the required NuGet packages
• dotnet run to run the application

That’s it! After doing this there will be an auto generated program.cs file in the new folder and a standard void Main() method for a console app, you can pick your text editing application and have at it, something like this…

public class Program
{
    public static void Main(string[] args)
    {
        var host = new WebHostBuilder()
            .UseKestrel()
            .UseStartup()
            .Build();

        host.Run();
    }
}

public class DoStuff
{
    public void Configure(IApplicationBuilder app)
    {            
        app.Run(async (context) =>
        {
            await context.Response.WriteAsync(
                "Doing stuff ... I promise ");                                                
        });
    }
}

Just seeing how quickly you can get started provides a great opportunity for teaching and hackathons, instead of spending the first 2 hours ensuring everyone is on the same page this setup process can just take minutes. This is great!

Middleware

HttpModules and Handlers were once my go to ASP.NET interview talking point I used to use it gauge if folks were “Senior” or not, however, that mechanism is no longer in the pipeline and we are left with the versatile Middleware, as defined below:

Middleware – Pass through components that form a pipeline between a server and application to inspect, route, or modify request and response messages for a specific purpose.

You can use Middleware to implement tasks as requests arrive such as authorizations, authentication, session state management etc. For starters though you might consider implementing existing Middleware (Authentication, Diagnostics, Routing, Working with Static Files), the following implements MVC in the pipeline.

public class DoStuff
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseMvc();
    }
}

There is so much more to talk about here (Services, Hosting), but I am hoping this sets the groundwork for future forays into the .NET Core space, I am especially interested in what this means for practical memory profiling in the IIS space.