Abbiamo scoperto che diversi progetti all'interno della stessa soluzione utilizzavano versioni diverse l'una dall'altra. Inoltre, un singolo progetto potrebbe avere una versione elencata nell'elemento <Reference>
dalla versione elencata nello HintPath
.
Abbiamo semplicemente esaminato ciascun file .csproj e modificato manualmente per sincronizzare tutto.
- Trova la riga che inizia con
<Reference
che include le informazioni per la DLL in questione.
- Questa riga dovrebbe indicare una versione. Ad esempio:
<Reference Include="SomeAssembly, Version=4.0.54">
. Potrebbe esserci del testo aggiuntivo dopo questo come Culture
e/o PublicKey
, ecc. Ci interessa solo l'attributo Versione.
- Prendere nota di questa versione.
- Ora controlla l'elemento
<HintPath>
all'interno di <Reference
, conterrà il percorso di quella DLL che VS si aspetterà (dove VS guarderà prima).
- Questo percorso conterrà anche una versione
..\packages\SomePackage.4.0.56\lib\net45\SomeAssembly.dll
(ad esempio, nel nostro caso si trattava di pacchetti Service Stack). Anche se questa non è tecnicamente una versione (è solo un percorso per un file sul tuo sistema), in genere corrisponde alla versione della DLL.
- È necessario assicurarsi che queste due cose siano sincronizzate - che il percorso elencato esiste effettivamente e che conduce alla dll prevista.
Nel nostro caso, ci siamo spostati da ServiceStack 4.0.54 a 4.0.56. Alcuni dei riferimenti Include
erano a 4.0.56 mentre il percorso indicava ancora la versione 4.0.54. Poiché il percorso suggerito non puntava alla dll attese VS guardò altrove e trovò quella che credeva fosse una corrispondenza accettabile nella directory \bin\debug
del progetto. Questa non era la versione corretta.
Spetterà alla tua situazione specifica su quale cambiare e su cosa.
Questo è stato probabilmente causato da scarse fusioni.
Inoltre abbiamo sgomberato le \bin
e \packages
directory sotto la cartella del progetto. Soluzione ricaricata e ripristino di Nuget. Questo è solo per chiarire le cose in modo che Nuget possa tirare fuori solo i pacchetti, e le loro versioni, di cui ha bisogno. Inoltre impedisce a VS di utilizzare versioni errate che potrebbero trovarsi nella directory \bin
del progetto. Entrambi sono sicuri da eliminare. La cartella \packages
verrà ricreata e popolata tramite il ripristino Nuget e la directory \bin
verrà ricreata e popolata sulla build successiva della soluzione.
fonte
2016-05-12 17:25:22
Lo vedo per tutti i pacchetti in un progetto, mentre quegli stessi pacchetti in altri progetti (tutti all'interno della stessa soluzione) utilizzano il percorso dei pacchetti "corretto". –
Non sono sicuro se è una risposta. Ho ottenuto il nostro fisso modificando i file csproj. Abbiamo avuto alcune versioni che sono state mescolate. Diversi progetti che utilizzano versioni diverse l'una dall'altra. La versione di riferimento diversa dalla versione elencata nel percorso, ecc. Quindi ho appena aperto tutto e pulito per essere lo stesso. –
@DavidMartin che ha funzionato! Ho commentato tutti i riferimenti di inclusione del contenuto e di riferimento nel file .csproj e la volta successiva che ho aggiunto il pacchetto ho aggiunto il percorso corretto. Cura di postare questo come una risposta in modo che io possa accettarlo? –