Revisiting ASP.NET Core 1.0

Back in August 2015, I wrote an article which showed how you could deploy an ASP.NET 5 application on our servers for those who wanted to try and test it out.  I also mentioned in the same article that because ASP.NET 5 was still in beta, what I wrote may or may not work for future releases.

I can now say they are no longer applicable.  They will still work for Beta6 but not for RC1 or RC2.  This article covers some of the changes made since Beta6 and why we chose not to support RC1.  ASP.NET 5 (vNext) has also been renamed to ASP.NET Core 1.0, and I’ll refer to it as such from now on.

We chose not to support RC1 for a couple of reasons.  In order deploy an RC1 application successfully, some changes need to be made on the back end.  RC1 requires the installation of an additional IIS module, the HTTPPlatformHandler.  It’s a pretty interesting module which allows you to run non-native Windows languages such as Java, Node.exe, Ruby, etc. under IIS.

But that wasn’t the main reason we chose not to support RC1.  RC1 just presented some technical challenges to overcome, mainly with how the file directory is setup and security (i.e. approot and wwwroot).

Since ASP.NET Core represents a paradigm shift in the way ASP.NET apps were being developed, integrating it with our current infrastructure while providing backwards compatibility for older versions of ASP.NET proved difficult.

There was also the problem with getting Web Deploy/FTP from Visual Studio working correctly which many of our current customers are familiar with and rely on to deploy their websites.  Since this was just a Release Candidate, we adopted a wait and see approach to see what further changes would be made to the product.

Fast forwarding to May 2016, that proved to be a wise decision.  RC2 helps address many of the issues we faced trying to integrate RC1 in our environment.  It no longer requires the HttpPlatformHandler in order to run, but instead relies on a new module, ASPNetCoreModule, developed specifically for Core and can be enabled with the addition of one line in your web.config file.

If you also examine the file structure of an RC2 application, you’ll also notice some major changes.  The approot folder is now gone, but the assemblies, runtimes, and configuration files are still stored outside of the wwwroot directory (either one file directory level above or adjacent to it).

What this means for us is that we no longer have to make changes to our file directory structure to accommodate/fix deployment and security issues such as the one mentioned in my previous article if you want to host the application in the root of your account.  RC2 applications can now be deployed the same way as any other type of application (e.g. MVC, web forms, etc.)

We’ve also been working directly with Microsoft to get Web Deploy working, and I can now say it’s possible to use Web Deploy to deploy an RC2 application with a few minor modifications to Visual Studio and your solution’s publishing profile.   Web deployment now looks and feels like what you’re used to.

We still have some testing to perform before we can roll this out to production, such as integrating the .NET Core Framework in order to support portable applications as opposed to self-contained applications, but you can rest assured that when we do, you’ll also have the technical expertise of a knowledgeable staff to help you get your ASP.NET Core application running on our servers.