blog post image
Andrew Lock avatar

Andrew Lock

~4 min read

Viewing what's changed in ASP.NET Core 1.0.1

On 13th September, Microsoft announced they are releasing an update to .NET Core they are calling .NET Core 1.0.1. Along with the framework update, they are also releasing 1.0.1 version of ASP.NET and Entity Framework Core. Details about the update can be found in a blog post by Microsoft.

The post does a good job of laying out the process you should take to update both your machine and applications. It also outlines the changes that have occurred, as well as the corresponding security advisory.

I was interested to know exactly what had changed in the source code between the different releases, in ASP.NET in particular. Luckily as all ASP.NET Core development is open source on GitHub, that's pretty easy to do!:)

Comparing between tags and branches in GitHub

A feature that is not necessarily that well known is the ability to compare between two tags and branches using a url of the form:

https://github.com/{username}/{repo}/compare/{older-tag}...{newer-tag}

This presents you with a view of all the changes between the two provided tags. Alternatively, navigate to a repository, select branches, click the compare button and select the branches or tags to compare manually.

Comparing between branches in GitHub

In the rest of the post, I'll give a rundown of the significant changes in the ASP.NET Core and EF Core libraries.

Changes in ASP.NET MVC

Most of the changes in the ASP.NET MVC repository are version changes of dependencies, incrementing from 1.0.0 to 1.0.1. Aside from these, there were a number of minor whitespace changes, comment changes, minor refactorings and additional unit tests. For the purpose of this post, I'm only going to focus on changes with a tangible difference to users. You can see the full diff here.

The first notable change is the handling of FIPS mode in the SHA256 provider. A static helper class, CryptographyAlgorithms, shown below, has been added to handle the case that you are running on a Windows machine with FIPS mode enabled. FIPS mode stands for 'Federal Information Processing Standard' and defines a set of approved cryptographic algorithms for US government computers - see here for a more detailed description. If you're not running applications on US federal computers, this change probably won't affect you.

using System.Security.Cryptography;

namespace Microsoft.AspNetCore.Mvc.TagHelpers.Internal
{
    public static class CryptographyAlgorithms
    {
#if NETSTANDARD1_6
        public static SHA256 CreateSHA256()
        {
            var sha256 = SHA256.Create();

            return sha256;
        }
#else
        public static SHA256 CreateSHA256()
        {
            SHA256 sha256;

            try
            {
                sha256 = SHA256.Create();
            }
            // SHA256.Create is documented to throw this exception on FIPS compliant machines.
            // See: https://msdn.microsoft.com/en-us/library/z08hz7ad%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396
            catch (System.Reflection.TargetInvocationException)
            {
                // Fallback to a FIPS compliant SHA256 algorithm.
                sha256 = new SHA256CryptoServiceProvider();
            }

            return sha256;
        }
#endif
    }
}

The second significant change is in MvcViewFeaturesMvcCoreBuilderExtensions. This class is called as part of the standard MVC service configuration for registering with the dependency injection container. The file has a single changed line, where the registration of ViewComponentResultExecutor is changed from singleton to transient.

Diff between MvcViewFeaturesMvcCoreBuilderExtensions

I haven't dug into it further, but I suspect this is where the privilege elevation security bug mentioned in the announcement arose. This really shows how important it is to configure your service lifetimes correctly. This is especially important when adding additional dependency to an already existing and configured class, to be ensure you don't end up with captured transient dependencies.

The final main change in the MVC repository fixes this issue whereby a DELETE route is incorrectly matched against a GET method. The commit message for the commit fixing the issue gives a great explanation of the problem, which boiled down to an overloaded == operator giving incorrect behaviour in this method. The fix was to replace the implicit Equals calls with ReferenceEquals.

Changes in AntiForgery

Much like the MVC repository, the AntiForgery repository uses a SHA256 algorithm. In order to not throw a TargetInvocationException when calling SHA256.Create() on FIPS enabled hardware, it falls back to the SHA256CryptoServiceProvider. Again, if you are not running on US Federal government computers then this probably won't affect you. You can view the diff here.

Changes in KestrelHttpServer

There is a single change in the Kestrel web server that fixes this bug, whereby replacing the Request.Body or Response.Body stream of the HttpContext causes it to be replaced for all subsequent requests too. This simple fix solves the problem by ensuring the streams are reset correctly on each request:

Resetting the frame streams

Other changes

I've highlighted the changes in ASP.NET Core 1.0.1, but there are also a tonne of minor changes in the Entity Framework Core library, too many to list here. You can view the full change list here. Finally, the CoreCLR runtime has fixed these three bugs (here, here and here), and the templates in the dotnet CLI have been updated to use version 1.0.1 of various packages.

Summary

This was just a quick update highlighting the changes in ASP.NET Core. As you can see, the changes are pretty minimal, like you'd expect for a patch release. However the changes highlight a number of bugs to keep an eye out for when writing your own applications - namely incorrect service lifetimes and potential bugs when overloading the == operators.

Andrew Lock | .Net Escapades
Want an email when
there's new posts?