When using Azure SignalR, cannot load Microsoft.Extensions.Logging.Abstractions

I am using Asp.Net MVC5 and trying to implement Azure SignalR with SQL dependency on our Azure database. I am able to run our app just fine, and I had local-hosted SignalR working previously as well, but when I try to use Azure SignalR and add:

    public partial class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            //starting azure signalR
            app.MapAzureSignalR(this.GetType().FullName);
        }
    }

To my Startup.cs class, along with the necessary connection string in web.config, I get this error:

Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I've tried uninstalling and re-installing the Azure SignalR NuGet packages, I've tried making sure the versions across my solution match (there are 10 projects), I've deleted the bin and obj folders, I've made sure the packages.config and .csproj files match the correct versions. At some points it asks for Version=2.1.0.0, and after switching back to that version, it then spouts another error for a different error for Microsoft.Aspnetcore, or Logging.Abstractions V1 again.

I'm really at a loss of where to go from here, I downloaded an Azure SignalR example in .net mvc5 and was able to get that working fine, but for some reason it doesn't work in this big solution. I'm new to development in general so any help would be greatly appreciated.

UPDATE: Taking advice on what to do next, I added a bindingRedirect in my Web.config for Microsoft.Extensions.Logging.Abstractions. This cleared the error, but gave the same one for .Logging. Added a bindingRedirect for that, and got the same error for Microsoft.Extensions.Options, did same thing and that fixed. But now I get this error:

Could not load file or assembly 'System.Memory, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

And even after adding this bindingRedirect, I still get the same error:

  <dependentAssembly>
        <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.5.3.0" newVersion="4.5.3.0" />
  </dependentAssembly>

I uninstalled and re-installed System.Memory nuget, checked packages.config, web.config, and the .csproj file and all of them match the same version.

As mxmissile noted, this is going to be a conflict between different versions being requested by different packages. As you noted, the SignalR package works fine on it's own, so it isn't an issue with that package specifically.

The fact that there are multiple projects shouldn't matter either- packages are installed on a per project basis, though ASP.NET will reuse them if the versions match. I won't say it's impossible for this happen, but it shouldn't based on how this works.

Without a full list of the packages and versions installed, this is going to be almost impossible to reproduce by someone else, however there are a couple things to do to try and track down the conflict.

1. Check the listing for the library in the Web.Config. There should be something like <bindingRedirect oldVersion="0.0.0.0-3.1.1.0" newVersion="3.1.1.0" /> for Microsoft.Extensions.Logging.Abstractions where 3.1.1.0 is the current version installed. Usually uninstalling/reinstalling clears this up if it was off. Not being able to repro the issue, I can't say for sure, but checking to make sure this is correct can solve the problem. I've also had instances in the past where removing the bindingredirect property completely resolved the conflict.
2. The second thing to do is a bit tedious, but should exactly pinpoint the issue. Take your project that currently just has SignalR and start adding the Nuget packages contained in the other project one by one, testing the build each time. Once the build fails, you'll know where the conflict is and can work on addressing it.
3. The bindingredirect property exists to prevent these kinds of issues, but if there is no other way, the codeBase property inside the dependantAssembly listing will let you direct the CLR to include more than once version of a given assembly. This makes the project more difficult to maintain since you'll need to manually update this listing if version requirements change.