2013-05-02 11 views
5

Il mio servizio in hosting utilizza Azure Storage 2.0 (esattamente 2.0.5.1 da Nuget). In Visual Studio 2010 non ho avuto problemi. Sono passato a Visual Studio 2012 e ora in qualche sito web del mio ruolo web principale ottengo la seguente eccezione di tipo Microsoft.WindowsAzure.Storage.StorageException:Errore nel caricamento di Azure Storage 2.0 - impossibile caricare Microsoft.Data.OData 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) 

mentre Azure 2.0.5.1 richiede Microsoft.Data.OData 5.2.0.0. Gli altri ruoli dei lavoratori funzionano bene e sembrano trovare l'assembly corretto. In ogni progetto Azure Storage 2.0 è installato da Nuget e tutti i riferimenti rimandano alla cartella packages.

Io uso Azure SDK 1.8 in .NET 4.0 - ciò significa che utilizzo anche Azure Storage Client 1.7.

risposta

4

Dopo una piccola indagine, ho scoperto che questo sito web caricato Microsoft.WindowsAzure.Storage dal percorso SDK, lo stesso percorso da cui ho caricato Microsoft.WindowsAzure.StorageClient in altre assemblee - nei moduli finestre in Visual Studio vedo che iisexpress carica l'assembly con la versione del file 2.0.0.0. A mio avviso, il riferimento a Microsoft.WindowsAzure.StorageClient può forzare Visual Studio a caricare Microsoft.WindowsAzure.Storage dal percorso errato.

Dopo un po 'di giocherellare, ho spostato l'assembly Microsoft.WindowsAzure.Storage dalla cartella SDK, costringendo Visual Studio a fare riferimento all'assembly scaricato da Nuget - in questo modo non ho avuto alcun problema.

Un'alternativa, potrei anche spostare Microsoft.WindowsAzure.StorageClient in un'altra posizione e modificare i riferimenti nel mio progetto, ma questo sarà abbastanza inutile dal momento che ho intenzione di passare interamente ad Azure Storage 2.0 (ad esempio, spero che in Azure SDK 2.0 Diagnostics utilizza Storage 2.0).

+2

È anche possibile utilizzare un reindirizzamento di binding che sembra essere quello che la libreria tenta di fare comunque. –

+0

@PhilCooper osservazione giusta. Normalmente preferirei rintracciare la causa del problema di caricamento dell'assieme, poiché può nascondere alcuni problemi "fondamentali" (ad esempio, in questo caso, gli assembly caricati dal percorso sbagliato) e solo come ultima risorsa (quando non riesco a trovare il causa del problema) utilizzare un reindirizzamento dell'assembly. – edymtt

Problemi correlati