Click here to Skip to main content
Click here to Skip to main content

Tagged as

When MVC5, SignalR and NuGet Just Won’t Get Along

, 13 Feb 2014
Rate this:
Please Sign up or sign in to vote.
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
This is obviously an exaggeration.

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 :

  1. Create a new Web Application Project in Visual Studio 2013 that uses built-in Forms Authentication (Individual User Accounts).
  2. Add the SignalR package through NuGet.
  3. Attempt to add the following code to your Startup.cs file :
    public partial class Startup
    {
            public void Configuration(IAppBuilder app)
            {
                // Add SignalR Mappings
                app.MapSignalR();
    
                ConfigureAuth(app);
            }
    }

If you did everything right, then grab some popcorn because you are about to see this :

FileLoadException

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">
           <!-- Other Assemblies here -->
           <dependentAssembly>
               <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
               <!-- Notice this targets 2.1.0.0 -->
               <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" />
               <!-- Notice this targets 2.1.0.0 -->
               <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">
        <!-- Other <assemblyBinding> elements for your Project -->
        <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">
        <!-- Other <assemblyBinding> elements for your Project -->
        <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

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Rion Williams
Software Developer (Senior)
United States United States
An experienced Software Developer and Graphic Designer with an extensive knowledge of object-oriented programming, software architecture, design methodologies and database design principles. Specializing in Microsoft Technologies and focused on leveraging a strong technical background and a creative skill-set to create meaningful and successful applications.
 
Well versed in all aspects of the software development life-cycle and passionate about embracing emerging development technologies and standards, building intuitive interfaces and providing clean, maintainable solutions for even the most complex of problems.
Follow on   Twitter

Comments and Discussions

 
QuestionThank you. PinmemberMember 25293936-Mar-14 5:50 
GeneralNice... PinmemberNitij Kumar14-Feb-14 5:40 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140814.1 | Last Updated 14 Feb 2014
Article Copyright 2014 by Rion Williams
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid