IApplicationBuilder exists in both Microsoft.AspNet.Http.Abstractions and Microsoft.AspNet.Http

Question

We're muddling thru doing authentication in ASP.NET 5. In this security sample, we see this type of thing:

app.Run(async context =>
{    
    var types = context.Authentication.GetAuthenticationSchemes();
}

Initial Problem

In our project, however, the HttpContext did not have an Authentication property and we would receive the following error:

Microsoft.Framework.Runtime.Roslyn.RoslynCompilationException: C:\myApp\Startup.cs(71,46): error CS1061:

'HttpContext' does not contain a definition for 'Authentication' and no extension method 'Authentication' accepting a first argument of type 'HttpContext' could be found (are you missing a using directive or an assembly reference?)

So, we looked at the source and found that its here inside the HttpAbstractions assembly. So, we added that assembly to our project.

Subsequent Problem

Unfortunately, we now receive the following error:

Microsoft.Framework.Runtime.Roslyn.RoslynCompilationException: C:\myApp\Startup.cs(43,31): error CS0433:

The type 'IApplicationBuilder' exists in both 'Microsoft.AspNet.Http.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' and 'Microsoft.AspNet.Http, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

Question

Fair enough. How can we ask the compiler to use the one assembly but not the other for this particular type? We've tried deleting .dnx\packages\Microsoft.AspNet.Http but it just comes back after dnu restore.

Answer 1

You've probably "crossed the streams", as is being said by the ASP.NET teams. Make sure you're following the breaking changes and aren't including packages from multiple beta versions (make sure you don't have both beta4 and beta5 referenced, for example - easiest way to check is search your project.lock.json for them.) The most common accidents come from using .Interfaces packages as most of those have been renamed to .Abstractions, but there have been other assembly naming changes (and removals, too!).

Update:

This error can also come up when you can't reach the NuGet packages via the servers you have configured and for the dnvm version you are running. (There was an update recently to dnvm that I had to upgrade in order to use the latest packages; seems that even within a single beta number the streams can still get crossed!) To get VS2015 to use a specific dnvm, a global.json may be required:

{
    "projects": [ "src", "tests" ],
    "sdk": {
        "version": "1.0.0-beta6-12005"
    }
}

Answer 2

Matt DeKrey was right. I needed not to cross the streams. In short, I needed beta6 and was on beta4. Here were the steps to fix:

1 Change project.json

It now looks like this

  "dependencies": {
    "Microsoft.AspNet.Server.IIS": "1.0.0-beta6",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta6",
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta6",
    "Microsoft.AspNet.Mvc": "6.0.0-beta6",
    "EntityFramework.SqlServer": "7.0.0-beta6",
    "EntityFramework.InMemory": "7.0.0-beta6",
    "Microsoft.AspNet.Identity": "3.0.0-beta6"
  }

2 Add a Nuget.config

Importantly, I needed to add a Nuget.config file to the root of my repository, because beta6 is not in NuGet yet.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/api/v2" />
    <add key="NuGet" value="https://nuget.org/api/v2/" />
  </packageSources>
</configuration>

The AspNetVNext entry is the Default Unstable that we see when we run dnvm.