J'ai un problème très particulier avec Azure Table Storage. J'ai un projet .NET 4.5 dans Visual Studio 2012 où je gère toutes mes fonctions Azure Table Storage. Ce projet/DLL est référencé par deux autres projets, mon site Web MVC et mon rôle de travailleur Azure. (Je fonctionne sous les émulateurs Azure sur ma machine, mais cela se produit également lorsque je le déploie dans le cloud)
J'ai la fonction suivante qui est appelée lorsque je sauvegarde ou récupère un enregistrement:
internal static CloudTable GetTable(CloudStorageAccount storageAccount, string tableReference)
{
CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
CloudTable table = tableClient.GetTableReference(tableReference);
table.CreateIfNotExists();
return tableClient.GetTableReference(table.Name);
}
Dans mon site Web MVC, j'ai une fonction qui enregistrera un enregistrement dans une table de stockage Azure, puis dans mon rôle de travailleur Azure, il y a un service qui lira l'enregistrement.
Par conséquent, les deux utilisent la même DLL pour le stockage et la récupération, mais mon projet MVC n'a aucun problème à sauvegarder l'enregistrement, mais dans mon service de rôle Azure Worker lorsqu'il essaie de récupérer l'enregistrement, il lève l'exception lorsqu'il tente d'exécuter "table.CreateIfNotExists () ; ".
Impossible de charger le fichier ou l'assembly "Microsoft.Data.OData, Version = 5.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35" ou l'une de ses dépendances. La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly. (Exception de HRESULT: 0x80131040)
J'ai déjà fait ce qui suit:
Je n'ai pas restauré la DLL à 5.2 car j'ai eu trop de problèmes dans d'autres projets où j'utilise des fonctionnalités spécifiques à partir de 5.3.
J'utilise actuellement toutes les DLL sur 5.5.
Lorsque j'exécute l'utilitaire AsmSpy.exe trouvé ici , j'obtiens la sortie suivante que je ne suis pas sûr à 100% comment interpréter.
> 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
Comment je l'interprète, c'est que la DLL Microsoft.WindowsAzure.Storage fait référence à la V 5.2.0.0 de la DLL Microsoft.Data.OData, mais comment résoudre ce problème, si tel est le problème? Selon la documentation que j'ai vue sur la DLL de stockage, c'est qu'elle est censée faire référence à 5.4 et plus, pas à 5.2 ...?
Ouvrir le problème pour un problème aussi facile à résoudre ne vous aidera pas.
Placez la configuration d'addition suivante dans vos fichiers de configuration respectifs (web.config pour le MVC et app.config pour le rôle de travail):
<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>
Notez que la section runtime
est un descendant direct de l'élément racine configuration
! Je suis sûr que vous avez déjà cette section dans votre web.config, car MVC4 l'utilise pour relier toutes les références à System.Web.MVC
à la dernière version.
Personnellement, je ne m'attends pas à ce que le SDK soit mis à jour avec chaque nouvelle version de chaque bibliothèque référencée! Ce serait de la folie ...
J'ai eu un problème très similaire mais dans ce cas, le message d'exception était;
Impossible de charger le fichier ou l'assembly "Microsoft.Data.OData, Version = 5.5.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35" ou l'une de ses dépendances. La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly. (Exception de HRESULT: 0x80131040)
notez qu'il essayait de charger la v5.5.0.0 de l'assembly OData.
Après avoir fouillé avec ILSpy ( http://www.ilspy.net ), j'ai découvert que Microsoft.WindowsAzure.Storage 2.0.0.0 faisait explicitement référence à Microsoft.Data.OData 5.2.0.0 - ce que je n'ai pas fait ai pas comme ma version était 5.5.0.0.
La solution consistait donc à utiliser le gestionnaire de packages NuGet pour désinstaller Microsoft.WindowsAzure.Storage, ce qui désinstallait Microsoft.Data.OData 5.5 à son tour. Puis à nouveau à l'aide du gestionnaire de packages NuGet, réinstallez Microsoft.WindowsAzure.Storage qui a identifié qu'il avait besoin de Microsoft.Data.OData 5.2 et l'a installé également.
et revenir à une solution de travail.
Vous pouvez résoudre ce problème en général chaque fois que vous mettez à jour des packages ou ajoutez de nouveaux packages via NuGet et que vous vous retrouvez avec des problèmes "Impossible de charger le fichier ou l'assembly ...".
Ouvrez la console du gestionnaire de packages ( VS 2012 Tools/Library Package Manager/Package Manager Console). Une fois le shell ouvert pour la console du gestionnaire de packages, exécutez la commande:
Add-BindingRedirect
Remarque: soyez prudent car l'exemple NugGet a ajouté un 's' à la fin dans leur exemple et Add-BindingRedirect
n'est pas une commande valide.
Cela fait ce qui suit:
Examine tous les assemblys du chemin de sortie d'un projet et ajoute des redirections de liaison au fichier de configuration d'application (app.config) ou au fichier de configuration Web (web.config) si nécessaire.
Vous pouvez voir la documentation complète de la console du gestionnaire de packages sur: http://nuget.codeplex.com/wikipage?title=Package%20Manager%20Console%20Command%20Reference%20 (v1.3)
En plus des deux entrées que vous voyez dans la réponse d'astaykov, ce qui suit a également été ajouté pour mon projet.
<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>
J'ai eu un problème similaire aujourd'hui. La seule différence que j'ai repérée est que mon application cloud cherchait (et ne parvenait pas à trouver) pour Microsoft.Data.OData dans la version = 5.2.0.0
En utilisant Visual Studio Object Browser, j'ai découvert que ma solution utilisait la bibliothèque de cet emplacement:
C:\Program Files (x86)\Microsoft WCF Data Services\5.0\bin\.NETFramework
La bibliothèque Microsoft.Data.OData qui y résidait se trouvait dans le ver. 5.0.0.0 donc l'écraser avec 5.2.0.0 a résolu le problème.
P.S. J'ai installé WCF Data Services Tools pour les applications du Windows Store plus tôt dans l'espoir de résoudre ce problème afin qu'il puisse arriver que votre application l'obtienne d'une autre source. Si tel est le cas, vous avez deux options:
Installez les outils WCF Data Services pour les applications du Windows Store à partir de ici et utilisez la solution ci-dessus.
Utilisez l'Explorateur d'objets Visual Studio pour trouver quelles versions de la bibliothèque OData sont actuellement visibles pour votre projet et où elles sont stockées. Vous devez ensuite en remplacer les versions incorrectes.
J'ai également eu un problème similaire, mais je n'utilisais pas Azure et il n'y avait aucune référence codée en dur qui pointait vers 5.2. Mais il a résolu (après avoir trouvé cet article ) en s'assurant que le texte dans le .svc pointait vers le bon assemblage:
<%@ ServiceHost Language="C#"
Factory="System.Data.Services.DataServiceHostFactory,
Microsoft.Data.Services, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Service = "MVC4WCFDataServiceFE5.NorthWindService"%>
Notez la version = 5.6.0.0 , que je n'avais pas auparavant.