This is obviously an exaggeration.
Sometimes, things just blow up.
If you have recently attempted to create a new ASP.NET MVC5 project (or any new Web Project within Visual Studio 2013) and decided that you wanted some of that sweet SignalR magic in your application, then you may have encountered the following error:
An exception of type ‘System.IO.FileLoadException
’ occurred in Microsoft.AspNet.SignalR.Core.dll but was not handled in user code.
Additional information: Could not load file or assembly ‘Microsoft.Owin, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35′ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT
: 0×80131040)
This can easily be reproduced through the following steps:
- Create a new Web Application Project in Visual Studio 2013 that uses built-in Forms Authentication (Individual User Accounts).
- Add the SignalR package through NuGet.
- Attempt to add the following code to your Startup.cs file:
public partial class Startup
{
public void Configuration(IAppBuilder app)
{
app.MapSignalR();
ConfigureAuth(app);
}
}
If you did everything right, then grab some popcorn because you are about to see this:
Why Is This Happening To Me?
Of all of the things to blame, we are going to choose NuGet for this one.
This is currently a known issue within NuGet. The reason for this is that SignalR and some other binaries are built with a dependency over Microsoft.Owin Version 2.0.0, however the appropriate assembly binding redirects are not occurring. This causes a problem as the latest available version of Microsoft.Owin
in the public NuGet feed is greater than 2.0.0.
Okay. But How Do I Fix It?
There are two options here, which I have each had success with so I’ll start with the easiest approach, installing a specific updated version of Microsoft.Owin
(and Microsoft.Owin.Security
) and ensuring that you are properly targeting it within your web.config.
You can do this within the following steps:
- Access the NuGet command-line tool within Visual Studio (accessible under Tools > Library Package Manager > Package Manager Console)
- Install an updated version of Microsoft.Owin and Microsoft.Owin.Security (2.0.1, 2.1.0, 2.2.0 or any other version) using the following command:
Install-Package Microsoft.Owin -Version 2.1.0
Install-Package Microsoft.Owin.Security -Version 2.1.0
- Ensure that your web.config has the appropriate <bindingRedirect> attributes to target the version you selected as seen below:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin"
publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.0.0" newVersion="2.1.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security"
publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.0.0" newVersion="2.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
The Other Longer and Seemingly Less Reliable (in my experience) Approach
This method appears to only work if the version of Owin that was installed through NuGet is already greater than one of the dependencies that you already have.
The second option involves creating a Console application and then add the SignalR package to it. Then copy the bindingRedirects
from the app.config file of this application to the web.config file in your previous exception-infested MVC application (as Console applications don’t have this same issue).
You really just need to update the oldVersion
and newVersion
attributes within the <bindingRedirect>
sections for your Microsoft.Owin
and Microsoft.Owin
assemblies within the <assemblyBinding>
section of your web.config from:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin"
publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.0.0"
newVersion="2.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security"
publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.0.0"
newVersion="2.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
to:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin"
publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.2.0"
newVersion="2.0.2.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security"
publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.2.0"
newVersion="2.0.2.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Or more simply, change the <bindingRedirect>
sections for each of your Owin-related assemblies from:
<bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
to:
<bindingRedirect oldVersion="0.0.0.0-2.0.2.0" newVersion="2.0.2.0" />
Filed under: CodeProject, Development