Could not load file or assembly Microsoft.Owin on Azure - asp.net

My ASP.Net MVC Application works fine when run locally on IIS, but gives the following error when deployed to Azure:
Could not load file or assembly 'Microsoft.Owin, Version=2.1.0.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: 0x80131040)
This is the piece of the stack trace that led me to believe that SignalR is a potential culprit:
[FileLoadException: Could not load file or assembly 'Microsoft.Owin, Version=2.1.0.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: 0x80131040)]
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, String path, HubConfiguration configuration) +0
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, HubConfiguration configuration) +12
QuikWorx.O365Web.Startup.Configuration(IAppBuilder app) +169
According to NuGet, I have version 3.0.1 of Microsoft.Owin installed on the application, but apparently something (SignalR) requires version 2.1.0. I would have thought that the following bindingRedirect would force SignalR to use the installed version 3.0.1 (verified present, version 3.0.1 in /bin on Azure):
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
</dependentAssembly>
...but alas, this is not the case.
I've also tried the following without success:
Forced reinstall of Microsoft.Owin 3.0.1 with NuGet.
Forced reinstall of the SignalR component (Microsoft.AspNet.SignalR.Core) that requires Microsoft.Owin 2.1.0 with NuGet
Changing the oldVersion of the bindingRedirect for Microsoft.Owin to "0.0.0.0-2.1.0.0" (this makes no sense)
Removing the bindingRedirect for Microsoft.Owin
Deleting all files and folders in the site directory using rd /Q /S in Kudu
Is there anything else that I could attempt?

Would love to get to the root cause of the issue, as in why it works locally, but not in Azure, but based on this answer you should probably try to install Microsoft OWIN itself - via NuGet, directly to the project that's failing.

Related

Wrong version of .NET assembly getting copied to Web Forms bin directory

I'm working on an ASP.NET Web Forms web site and frequently get run-time exceptions like the following:
Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
=== Pre-bind state information ===
LOG: DisplayName = Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
(Fully-specified)
LOG: Appbase = file:///C:/Code/MyProject/
LOG: Initial PrivatePath = C:\Code\MyProject\bin
Calling assembly : System.Net.Http.Formatting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Code\MyProject\web.config
LOG: Using host configuration file: \\foo\bar\Profile.v2\simonm\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.5.0.0 redirected to 11.0.0.0.
LOG: Post-policy reference: Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: Attempting download of new URL file:///C:/Users/simonm/AppData/Local/Temp/Temporary ASP.NET Files/vs/8d6ca9e7/1d38a78a/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/simonm/AppData/Local/Temp/Temporary ASP.NET Files/vs/8d6ca9e7/1d38a78a/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Code/MyProject/bin/Newtonsoft.Json.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
They're invariably because the "wrong" version of an assembly (it always seems to be Newtonsoft.Json) gets copied to the Bin directory despite the fact that the packages.config in the root of the site has:
<package id="Newtonsoft.Json" version="11.0.2" targetFramework="net45" />
and the web.config contains:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>
Can somebody please explain what dictates which assembly gets copied to the Bin directory, why this keeps happening and how to prevent it from happening in the future?
I guess, that some of your used frameworks/libraries are using different versions of Newtonsoft.Json. First, check your frameworks/libraries if they are requiring different versions of the Newtonsoft.Json library.
When you detected which is the (minimum) required version of Newtonsoft.Json try to reinstall this version through Nuget.
This seems to be cause by a number of factors, but ultimately boils down to having a .refresh file in the Bin directory that points to a different version of the assembly than the one referenced in the web.config.
It looks like these .refresh files get added when you (either manually or automatically due to e.g. Update-Package) add a reference to an ASP.NET project. If you look at the contents of a .refresh file, it's just the path to a .dll file. When you build, MSBuild (I assume) checks whether the Foo.dll in your Bin directory matches the one referenced by Foo.dll.refresh and, if they don't, copies the one referenced by the .refresh file into your Bin.
I think this combined with switching branches in Git to one that has a reference to a different version referenced in the web.config combined with the .refresh files not being in version control is what causes these problems.

Project works locally but crashes on Azure

I just published my project to Azure and all the sudden I get the following error:
Could not load file or assembly 'System.Web.Cors, Version=5.0.0.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: 0x80131040)
I have not updated/installed any nuget packages since the last publish.
Furthermore I just checked the .dkk file and copy local is set to true.
What could be the issue here? I haven't changed anything.
On a sitenode my project works fine locally.
This is surely coming cause of your DLL version is different OR DLL is missing on that environment.
Few steps you require to check:
Cors DLL should be there in your BIN directory [On Azure]
If it's there then Version of DLL deployed on server and your local both should be same. [You can check in properties]
If your version of Cors DLL higher on Azure server, compare to local one then you can
<dependentAssembly>
<assemblyIdentity name="System.Web.Cors" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-5.0.0.0" newVersion="5.0.0.1" />
</dependentAssembly>
Your new version could be your DLL version which are availbale into the BIN directory.

Running two versions of MongoDB assemblies at the same time

All,
My Project - (VS 2010 / .NET 4 / ASP.NET application, my web application lives inside Sitefinity as a Sitefinity application)
I have two versions of the MongoDB assemblies. I would like to run these side-by-side in my web application. Here's my setup:
\bin\AuxFiles\[1.8.3.9] assemblies
\bin\[1.4.x.x] assemblies
Web config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MongoDB.Bson" publicKeyToken="f686731cfb9cc103" culture="neutral" />
<codeBase version="1.4.2.4500" href="bin\MongoDB.Bson.dll" />
<codeBase version="1.8.3.9" href="bin\AuxFiles\MongoDB.Bson.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="MongoDB.Driver" publicKeyToken="f686731cfb9cc103" culture="neutral" />
<codeBase version="1.4.2.4500" href="bin\MongoDB.Driver.dll" />
<codeBase version="1.8.3.9" href="bin\AuxFiles\MongoDB.Driver.dll" />
</dependentAssembly>
</assemblyBinding>
When the application starts, it loads the 1.4.x.x assemblies by default. When I go to the page that uses the 1.8.3.9 version of assemblies I get an error:
Server Error in '/' Application.
Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Source Error: ....
Source File: ...... Line: 18
Assembly Load Trace: The following information can be helpful to determine why the assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' could not be loaded.
=== Pre-bind state information ===
LOG: DisplayName = MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103
(Fully-specified)
LOG: Appbase = file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/
LOG: Initial PrivatePath = C:\DEV\Visual Studio 2010\WebStoreApp\WebStoreApp\bin
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\DEV\Visual Studio 2010\WebStoreApp\WebStoreApp\web.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/bin/MongoDB.Driver.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Stack Trace:
[FileLoadException: Could not load file or assembly 'MongoDB.Driver, Version=1.8.3.9, Culture=neutral, PublicKeyToken=f686731cfb9cc103' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +51
System.Web.UI.Control.OnLoad(EventArgs e) +92
System.Web.UI.Control.LoadRecursive() +54
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint
UPDATE 1:
I have tried to rename my new 1.8.x.x assemblies from MongoDB.Driver.dll to MongoDB.Driver.exe so the files can co-exist under same directory (the older assemblies have extension .dll, the new version of the assemblies have extension .exe) but the loader seems not to pickup the assemblies. My understanding is that the loader always tries .dlls first, then tries .exes second. I am a bit puzzled.
UPDATE 2:
I have created a console application w/ exactly identical setup of my dual references and the app config entries that you see here,- and the application works, it executes 2 versions of the Mongo dll. The question is now, why doesn't this setup work in my Web application? Are my directories wrong? If you look below at the probing for the assemblies, it never checks my AuxFiles directory, it appears it simply ignores my configuration for side-by-side execution in web.config.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/d73c4379/cb2aee95/MongoDB.Driver/MongoDB.Driver.DLL.
LOG: Attempting download of new URL file:///C:/DEV/Visual Studio 2010/WebStoreApp/WebStoreApp/bin/MongoDB.Driver.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
UPDATE 3:
Found the issue but I am not sure of the details of this solution. The web.config file has 'configuration' root element w/ the following namespace declaration - 'xmlns=http://schemas.microsoft.com/.NetConfiguration/v2.0'.
The root element is fine but the specified namespace is causing my 'runtime' element to be ignored. Removing the namespace from the configuration element fixes everything.
Found the issue:
The 'configuration' root element in the web.config file contains the following namespace declaration - 'xmlns=http://schemas.microsoft.com/.NetConfiguration/v2.0'. Removing the namespace from the configuration element fixes everything.
Why the ns? It is more of a bug then anything in VS and has really no real purpose but mess up your intellisense and in my case the runtime configuration. Read more about it:
http://weblogs.asp.net/scottgu/archive/2005/12/02/432077.aspx

Bin deployed DLLs priority over GAC'd DLL's for Web app?

I am having a problem where an older GAC'd assembly is being used instead of a newer version assembly in the bin.
Server:
Assembly version: ASP.NET MVC 3 RC 1 (3.0.11029.0)
Full name: System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Code base: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Web.Mvc/v4.0_3.0.0.0__31bf3856ad364e35/System.Web.Mvc.dll
Deployment: GAC-deployed
Development machine:
Assembly version: Unknown version (3.0.20105.0)
Full name: System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Code base: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Web.Mvc/v4.0_3.0.0.0__31bf3856ad364e35/System.Web.Mvc.dll
Deployment: GAC-deployed
The newer RTM version (3.0.20105.0) is in the bin directory of the application. However, the application is using the one in the GAC instead of the local bin. My experience from windows applications is the local bin deployed DLL always takes precedence because the GAC is checked only if the DLL isn't found in the same directory as the application. This convention appears to not be the case for a web application.
How can I force it to use my newer version bin deployed DLL (3.0.20105.0)?
Edit:
I actually did try a binding redirect like so:
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="3.0.11029.0" newVersion="3.0.20105.0" />
I tried several variations on the oldversion such as 0.0.0.0-4.0.0.0. In all my attempts usually it either loaded the older version, or gave me this exception message:
Could not load file or assembly 'System.Web.Mvc' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
The binding log didn't have any errors except this was last two lines:
WRN: Comparing the assembly name resulted in the mismatch: Build Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Answered is SO Dll in both the bin and the gac, which one gets used? Note, you must run strong name hijack or it will use the GAC version.
I would retag this, it is not MVC specific.
You can modify your .config files to use assembly binding redirection for this and force the runtime to load different versions as you require.

ASP.NET exception error mentions old version of MySQL.Data that is not used in app

This exception is not showing when debugging locally and shows up only when i browse to the remote url address of the server..
I have FTP'd the MVC 3 app to my remote server and a check of the Bin folder there shows that I have all three MySQL reference assemblies. All are version 6.4.4.0.
In my web.config file all of the version numbers relating to those are set to version 6.4.4.0.
Why am I getting this error message about version 6.3.6.0, and how can this be solved?
Could not load file or assembly 'MySql.Data, Version=6.3.6.0,culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'MySql.Data, Version=6.3.6.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
There are a lot of things to check with this, but the most common one I've run accross was resolved by making sure the assembly is referenced correctly in the Visual Studio project and that the information is correct in the web.config.
In Visual Studio, check the properties on the references for the assemblies
verify the the version listed.
check if Specific Version is true/false.
check if Copy Local is true.
If the version is wrong, you may have to remove and re-add the reference.
I would guess the exception was not thrown on your local machine because the older version of the assemblies are available on your machine.
The reason your local information is showing in the exception is unrelated to the assembly reference issue. Your local system is where the assembly was built, and so that information is built in for debugging purposes. (If this exception was thrown while you were debugging, VS would bring you to that line of that file.)
Ok I was worried that I somewhere along the way bits of 6.3.6.0 where left on my system from when I had it installed.. After days of trying to figure this one out I actually have come up with the fix for this issue... I just simply needed to overwrite the version information using assembly binding in the web.config. Once I did that it loads from the remote server error free... Here is what I added to my web.config:
<dependentAssembly>
<assemblyIdentity name="MySql.Data" publicKeyToken="c5687fc88969c44d" />
<bindingRedirect oldVersion="0.0.0.0-6.3.6.0" newVersion="6.4.4.0" />
</dependentAssembly>
Could you please explain where I put the "Copy local = true" I do not see it as being part of any property window. I did find "Always Copy" for the resources. also where does this go in the web.config
<dependentAssembly>
<assemblyIdentity name="MySql.Data" publicKeyToken="c5687fc88969c44d" />
<bindingRedirect oldVersion="0.0.0.0-6.3.6.0" newVersion="6.4.4.0" />
</dependentAssembly>
I ran the package manager console and then used this to fix this problem:
PM> Install-Package MySQL.Data.Entities

Resources