Could not load file or assembly Microsoft.Data.OData Version=5.2.0.0 error in Azure Cloud Worker Role using Table Storage

Question

I have a very peculiar issue using Azure Table Storage. I have a .NET 4.5 project in Visual Studio 2012 where I deal with all my Azure Table Storage functions. This project/dll is referenced by two other projects, my MVC website, and my Azure Worker Role. (I am running under the Azure Emulators on my machine, but it also happens when I deploy it to the cloud)

I have the following function that is called when I save or retrieve a record:

internal static CloudTable GetTable(CloudStorageAccount storageAccount, string tableReference)
{
    CloudTableClient tableClient = storageAccount.CreateCloudTableClient();

    CloudTable table = tableClient.GetTableReference(tableReference);
    table.CreateIfNotExists();

    return tableClient.GetTableReference(table.Name);
}

In my MVC website I have a function that will save a record to a Azure Storage table, and then in my Azure Worker Role there is a service that will read the record.

So both uses the same dll for storage and retrieval, however my MVC project has no issues saving the record, but in my Azure Worker role service when it tries to retrieve the record throws the exception when it attempts to execute "table.CreateIfNotExists();".

Could not load file or assembly 'Microsoft.Data.OData, Version=5.2.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 done the following already:

1. Updated all the NuGet packages from the solution level to the latest versions
2. I went through every project reference to make sure that there are no old dll's or previous versions hanging around, in particular the System.Spatial, Microsoft.WindowsAzure.Configuration, Microsoft.WindowsAzure.ServiceRuntime and Microsoft.ServiceBus, Microsoft.WindowsAzure.Storage, Microsoft.Data.Edm & Microsoft.Data.OData
3. I have even created a new Cloud Service and WorkerRole project from scratch to make sure it is not something in the current WorkerRole project that is broken.

I have not rolled the dll's back to 5.2 as I had too many issues in other projects where I use features that are specific from 5.3 onwards.

I am currently running all the dll's on 5.5.

When I run the AsmSpy.exe utility found here, I get the following output that I am not 100% sure how to interpret.

> Reference: Microsoft.Data.Edm
>         5.5.0.0 by Microsoft.Data.OData
>         5.5.0.0 by Microsoft.Data.Services.Client
>         5.5.0.0 by Microsoft.WindowsAzure.ActiveDirectory.GraphHelper.2013_04_05
> Reference: System.Spatial
>         5.5.0.0 by Microsoft.Data.OData
>         5.5.0.0 by Microsoft.Data.Services.Client Reference: Microsoft.Data.OData
>         5.5.0.0 by Microsoft.Data.Services.Client
>         5.2.0.0 by Microsoft.WindowsAzure.Storage   <-- THIS SEEMS TO BE THE ONE THAT IS CAUSING ISSUES

How I interpret it, is that the Microsoft.WindowsAzure.Storage dll is referencing V 5.2.0.0 of the Microsoft.Data.OData dll, but how do I fix this, if this is the issue? According to the documentation I have seen on the Storage dll is that it is supposed to reference 5.4 and up, not 5.2...?

Asterisk

I have opened an issue on Github [github.com/WindowsAzure/azure-sdk-for-net/issues/214] so hopefully this is the problem, and they can fix it asap. – Asterisk

I suggest that you close that issue – Extent

I have closed it. Thanks – Asterisk

It is also possible to use live.sysinternals.com/dbgview.exe at runtime to detect this type of problem. That is how I found the cause of the mysterious failures on the published version of my webrole. – Ceil

Answer 1

Opening issue for such an easy to solve issue will not help you.

Put the following addition configuration in your respective config files (web.config for the MVC and app.config for the worker role):

 <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Note that runtime section is direct descendant of the configuration root element! I'm pretty sure you already have this section in your web.config, because MVC4 uses it to rebind all references to System.Web.MVC to the latest version.

I personally do not expect the SDK to be updated with every new version of every referenced library! This would be madness...

Extent

Thank you, that fixed it, but I have to disagree with you. Microsoft is changing the way they update/deploy things from a 12/18 month path to a rapid upgrade/deployment using NuGet and regular updates. This makes the management of dll versions more critical than in the past where they changed once a year, to now they are changing once a week on these Azure packages. So to help us not battle the dll version hell, they should at least then create the NuGet packages to update the config files automatically. Now that I know it is simple, but I spent 2 days getting here. Thanks for it! – Asterisk

I also disagree that this was "easy to solve", but thanks for the answer, as it saved me a little time as well. – Arteriosclerosis

Assembly binding redirection has been used for almost a decade. And you can easily find it nowadays even in Microsoft project template's config files. Please don't tell me this is not extremely easy to solve such type issues, just because you didn't know about that feature! – Extent

See my answer below to solve this for the general case whenever this happens when updating or adding packages via NuGet. There is a one line command "Add-BindingRedirect" that you can run from the NuGet Package Manager Console that makes solving the issue very easy. – Brucie

Although I do not mean to agree or disagree with anyone of the previous comments, after trying all of the suggested options I still get the initial error message. I refer to Microsoft.Data.Edm version 5.0.2.0; Microsoft.Data.OData version 5.0.2.0 and System.Spatial version 5.0.2.0; After de-installing and re-installing serveral of the thingds using NuGet, the error remains, appearently regardless of any other versions of the references files I use. So in the end I'm still stuck with this issue and look for a solution not that MIGHT work, but that simply WORKS! Is that much to ask? – Fortuity

@Extent - Looking at the number of times this issue has been viewed since it has been up, and the comments received, I think it is fair to say that you guys have a potential 'thorn' here that needs to be looked at. It is frustrating and causing much frustration around the community. I dont care that assembly binding has been around for a long time. The simple fact is that now with the NuGet age, this needs to be looked at again, and fixed. – Asterisk

@Ryk, you have a point. But here is the community. Feedback for Microsoft products you can give at connect.microsoft.com. If you don't know, Microsoft MVP does not mean I work for, or am affiliated by Microsoft in any way! I am just an experienced developer/consultant, who apparently has a solution for issues. If you think, this particular issue should be raised to Microsoft, StackOverflow is definitely not the place to do so. If you have a better solution - post it here. This is how StackOverflow works! – Extent

See @eesh's answer below, I needed System.Spatial as well to resolve the problem. – Fergus

This fixed the issue for me as well but this is concerning - I agree with @Peter Klein above. NuGet, even with the Add-BindingRedirect option, does not help here. How are we supposed to "just know" to add the redirect for the OData and Edm? Feels like we are doing something wrong but I cant tell what. In my case, it is just a default WebApi project - nothing added or removed, just the defaults the MS generates for that project type. – Sepsis

There is some basic rule that we all need to understand - When lookin at dependencies list, NuGet installs the minimum required version, regardless which the latest version is. I believe that if you, I, we, manually update all the packages on a fresh solution, before we are making any changes, the things will simply work as Peter Klein wants ... – Extent

UNfortunately fresh solutions work fine in demo's and trials. If I speak for myself, that only happens once in a while. Most of the time you, we, I spend on maintenance of existing solutions. And that is precisely the point where the hassle starts. – Fortuity

Is there a way to 'remove' the version-dependency forever, so I won't have to update the binding upon each NuGet package update? – Bossy

Usually every NuGet package should take care of these updates. For the cases it does not work - you end up here by that question. You will become very famous if you invent the way to remove version dependencies and still have a working solution when you update individual packages. – Extent

Answer 2

I had a very similar problem but in this case it exception message was;

Could not load file or assembly 'Microsoft.Data.OData, Version=5.5.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)

note it was trying to load v5.5.0.0 of the OData assembly.

After some digging around with ILSpy (http://www.ilspy.net) I discovered that Microsoft.WindowsAzure.Storage 2.0.0.0 was explictly referencing Microsoft.Data.OData 5.2.0.0 - which I didn't have as my version was 5.5.0.0.

So the solution was to use the NuGet package manager to uninstall Microsoft.WindowsAzure.Storage, this inturn uninstalled Microsoft.Data.OData 5.5. Then again using the NuGet package manager, reinstall Microsoft.WindowsAzure.Storage which identified that it needed Microsoft.Data.OData 5.2 and installed that too.

and back to a working solution.

Bookplate

There are problems with the way binaries are resolved in MSBuild that can lead to this error. As you discovered, aside from creating a post-build event that copies DLLs manually, sometimes the only solution is to simply keep the expected version dependency. The problem has to do with MSBuild's unification engine or something. – Cannabis

As this solution does not involve any editing of Config files, just a slightly annoying nuget uninstall and reinstall. it is a shame it is not higher up the answer ranking. – Insolence

Answer 3

You can solve this issue in general whenever you update packages or add new packages via NuGet and end up with "Could Not Load file or Assembly..." issues.

Open the Package Manager Console (VS 2012 Tools/Library Package Manager/ Package Manager Console). Once the shell opens for the Package Manager Console run the command:

Add-BindingRedirect

Note: Be careful as the NugGet example added an 's' to the end in their example and Add-BindingRedirect is not a valid command.

This does the following:

Examines all assemblies in the output path for a project and adds binding redirects to the application configuration (app.config) file or to the web configuration (web.config) file where required.

You can see complete documentation for the Package Manager Console at: http://nuget.codeplex.com/wikipage?title=Package%20Manager%20Console%20Command%20Reference%20(v1.3)

In addition to the two entries you see in astaykov's answer the following was also added for my Project.

  <dependentAssembly>
    <assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
  </dependentAssembly>

Brucie

I did not vote you down, but I can imagine why people did that: while your solution should work, when I tried it, the command did not appear to have any effect. Manually adding the redirects (as in the answer of astaykov) seems more reliable, but of course has the disadvantage that one needs to get the version exactly right and update manually on a new OData release. – Ceil

Interesting. I did actually run this and verify the inserted text in my web.config file. I would not have added this as an answer unless it actually worked (at least it worked for me). Strange but not that surprising that it did not have any effect on your file. Do you have a web.config or app.config file? – Brucie

Perhaps you have to choose the correct 'Default Project' in the package manager console for this to work? Much like you have to do for Install-Package – Dongdonga

Add-BindingRedirect isn't present in the newer versions of NuGet. – Bossy

I was stuck for long and this helped/solved the issue (I'd give more than an upvote) - works! – Superman

Answer 4

I had similar problem today. The only difference I spotted is my cloud app was looking (and failing to find) for Microsoft.Data.OData in Version=5.2.0.0

Using Visual Studio Object Browser i found out that my solution used library from that location:

C:\Program Files (x86)\Microsoft WCF Data Services\5.0\bin\.NETFramework

Microsoft.Data.OData library residing there was in ver. 5.0.0.0 so overwriting it with 5.2.0.0 resolved the problem.

P.S. I installed WCF Data Services Tools for Windows Store Apps earlier in hope of resolving this issue so it may happen that your application gets it from another source. If that is the case you have two options:

1. Install WCF Data Services Tools for Windows Store Apps from here and use solution above.

2. Use Visual Studio Object Browser to find what versions of OData library are currently visible for your project and where they are stored. Next you need to overwrite improper versions of them.

Bellflower

Answer 5

I had a similar problem as well, but I wasn't using Azure and there was no hard-coded reference that was pointing to 5.2. But it resolved (after finding this article) by making sure that the text in the .svc pointed to the correct assembly:

<%@ ServiceHost Language="C#"
      Factory="System.Data.Services.DataServiceHostFactory,
      Microsoft.Data.Services, Version=5.6.0.0,
      Culture=neutral, PublicKeyToken=31bf3856ad364e35"

Service="MVC4WCFDataServiceFE5.NorthWindService" %>

Note the Version=5.6.0.0, which I didn't have before.

Daria