2013-05-02 4 views
5

Mein gehosteter Dienst verwendet Azure Storage 2.0 (genau 2.0.5.1 von Nuget). Unter Visual Studio 2010 hatte ich kein Problem. Ich wechselte zu Visual Studio 2012 und jetzt in irgendeiner Website meiner Haupt Webrolle erhalte ich die folgende Ausnahme vom Typ Microsoft.WindowsAzure.Storage.StorageException:Fehler beim Laden von Azure Storage 2.0 - konnte Microsoft.Data.OData nicht laden 5.0.2

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

während Azure Storage 2.0.5.1 Microsoft.Data.OData 5.2.0.0 erfordert. Die anderen Worker-Rollen funktionieren einwandfrei und sie scheinen die richtige Assembly zu finden. In jedem Projekt wird Azure Storage 2.0 von Nuget installiert und alle Referenzen verweisen auf den Ordner packages.

Ich verwende Azure SDK 1.8 unter .NET 4.0 - das bedeutet, dass ich auch Azure Storage Client 1.7 verwende.

Antwort

4

Nach einer kleinen Untersuchung entdeckte ich, dass diese Website Microsoft.WindowsAzure.Storage aus dem SDK-Pfad, von dem der gleiche Weg, den ich Microsoft.WindowsAzure.StorageClient in anderen Baugruppen geladen geladen - in den Modulen Fenster in Visual Studio kann ich sehen, dass iisexpress Lasten der Montage mit der Dateiversion 2.0.0.0. Nach meinem Verständnis kann der Verweis auf Microsoft.WindowsAzure.StorageClient Visual Studio zwingen, Microsoft.WindowsAzure.Storage vom falschen Pfad zu laden.

Nach ein bisschen fiedeln, habe ich die Microsoft.WindowsAzure.Storage Assembly aus dem SDK-Ordner verschoben, Visual Studio gezwungen, auf die von Nuget heruntergeladene Assembly zu verweisen - so hatte ich kein Problem.

Eine Alternative, ich könnte auch Microsoft.WindowsAzure.StorageClient an einen anderen Ort verschieben und die Referenzen in meinem Projekt ändern - aber das wird ziemlich nutzlos sein, da ich plane, vollständig zu Azure Storage 2.0 zu verschieben (zum Beispiel hoffe ich, dass in Azure SDK 2.0 Diagnostics verwendet Storage 2.0).

+2

Sie könnten auch eine verbindliche Umleitung verwenden, die anscheinend die Aufgabe der Bibliothek ist. –

+0

@PhilCooper richtige Beobachtung. Normalerweise würde ich lieber die Ursache des Ladeproblems der Baugruppe aufspüren, da sie einige "grundlegende" Probleme verbergen kann (zum Beispiel in diesem Fall Assemblys, die aus dem falschen Pfad geladen wurden), und nur als letztes Mittel (wenn ich die Ursache des Problems) eine Baugruppenumleitung verwenden. – edymtt