Visual Studio 2017 - Impossibile caricare il file o l'assembly "System.Runtime, Version = 4.1.0.0" o una delle sue dipendenze

Sto usando Visual Studio 2017 e sto provando a creare una libreria .Net Standard 1.5 e usarla in un progetto di test .Net 4.6.2 nUnit.

Ricevo il seguente errore ...

Impossibile caricare il file o l'assembly "System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" o una delle sue dipendenze. Il sistema non trova il file specificato.

Ho provato quanto segue:

1. Riferimento alla libreria Std come riferimento del progetto. Errore: mi dà l'errore precedente.
2. Crea un pacchetto NuGet per la mia libreria Std e fai riferimento a questo. Errore: il tipo è System.String, in attesa di System.String. Questo perché System.Runtime ha finito per essere referenziato dal progetto e ha definizioni per tutti i tipi standard.
3. Riferimento NuGet pkg NetStandard.Library. Errore: dammi lo stesso errore di # ("Il tipo è System.String, in attesa di System.String"). NOTA: prima di farlo, ho cancellato TUTTI i pacchetti NuGet dal progetto e poi ho aggiunto solo i pacchetti nUnit e NetStandard.Library (che installavano altri 45 pacchetti).

è un insetto? C'è una soluzione? Qualsiasi aiuto è apprezzato.

Ho avuto lo stesso problema e nessuna soluzione suggerita che ho trovato ha funzionato. La mia soluzione per questo problema era: controlla App.config e packages.config per vedere se le versioni corrispondono.

Originariamente il mio app.config conteneva:

<dependentAssembly>
  <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Ma il packages.config conteneva:

<package id="System.Runtime" version="4.3.0" targetFramework="net461" requireReinstallation="true" />

Ho modificato la voce app.config in modo che corrisponda a packages.config per la newVersion:

<dependentAssembly>
  <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.3.0" />
</dependentAssembly>

Dopo la modifica, il problema è stato risolto.

Questo problema si verifica quando si fa riferimento a un progetto .NET Standard da un progetto .NET 4.x: nessuno dei riferimenti al pacchetto nuget del progetto .NET Standard viene importato come dipendenze.

Per risolvere questo problema, è necessario assicurarsi che il file csproj .NET 4.x punti agli strumenti di compilazione correnti (almeno 14):

<Project ToolsVersion="15.0">...

Quanto segue non dovrebbe più essere necessario, è stato risolto intorno a VS 15.3:

C'era un bug noto in VS2017, in particolare in NuGet 4.0.

Per aggirare il bug, dovrai aprire il file .csproj per il tuo progetto .NET 4.x e aggiungere questo snippet:

<ItemGroup>
  <PackageReference Include="Legacy2CPSWorkaround" Version="1.0.0">
    <PrivateAssets>All</PrivateAssets>
  </PackageReference>
</ItemGroup>

NuGet 4.x porta con sé il "riferimento al pacchetto" - non più packages.config - ma la vecchia pipeline 4.x non è stata completamente aggiornata al momento del lancio di VS2017. Il frammento di codice precedente sembra "svegliare" il sistema di compilazione per includere correttamente i riferimenti ai pacchetti dalle dipendenze.

Ho riscontrato questo problema di recente e ho provato molte cose menzionate in questo thread e in altri. Ho aggiunto riferimento pacchetto per "System.Runtime"dal gestore di pacchetti NuGet, fissato il redicts vincolanti in app.config, e assicurarsi che app.confige package.configla stessa versione per il montaggio. Tuttavia, il problema persisteva.

Infine, ho rimosso il <dependentAssembly>tag per l'assemblaggio e il problema è scomparso. Quindi, prova a rimuovere quanto segue nel tuo file app.config.

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.1.0" />
</dependentAssembly>

Modifica: dopo aver aggiornato .NET Framework alla 4.7.2, il problema è riemerso. Ho provato il trucco sopra ma non ha funzionato. Dopo aver perso molte ore, mi sono reso conto che il problema si verifica a causa di un vecchio System.Linqriferimento in app.config. Pertanto, rimuovere o aggiornare tutti i riferimenti Linq anche per eliminare questo problema.

Credimi, non sto scherzando. Rimuovi tutte le dipendenze System.Runtime dal tuo app.config e inizierà a funzionare.

Ho risolto l'errore facendo riferimento a NetStandard.Library e al seguente file app.config nel NUnit-Project.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="System.Reflection" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="System.Runtime.InteropServices" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.1.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

modificare

Se manca qualcosa di diverso da System.Runtime, System.Reflectiono System.Runtime.InteropServicesmanca (ad esempio System.Linq), aggiungi semplicemente un nuovo dependentAssemblynodo.

Modifica 2

Nelle nuove versioni di Visual Studio (2017 15.8 credo) è possibile che Studio crei il file app.config. Basta selezionare la casella di controllo Genera automaticamente i reindirizzamenti di associazione in Proprietà del progetto - Applicazione .

Modifica 3

La generazione automatica di reindirizzamenti di associazione non funziona bene con le librerie di classi .NET. L'aggiunta delle seguenti righe ai file csproj risolve il problema e verrà generato un file .config funzionante per Classlibary.

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

L'ho risolto eliminando il mio app.configcon

<assemblyIdentity name="System.Runtime" ....> 

inserimenti.

app.config è stato aggiunto automaticamente (ma non necessario) durante il refactoring

Questo problema si verifica quando si fa riferimento a un progetto .NET Standard da un progetto .NET 4.x: nessuno dei riferimenti al pacchetto nuget del progetto .NET Standard viene importato come dipendenze.

Ho risolto aggiungendo il 4.3pacchetto System.Runtime e NETStandard.Library e !! important !! Uso lo strumento refactor per cercare la versione System.Runtime.dll, 4.1.1.1non lo è 4.3e quindi aggiungere un bindingRedirect in .config

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="4.1.1.1" />
</dependentAssembly>

è troppo tardi lo so, tuttavia non c'è una risposta riuscita. Ho trovato la risposta da un altro sito web. Ho risolto il problema eliminando la dipendenza dall'assembly System.Runtime. L'ho cancellato.

<dependentAssembly> <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0"/> </dependentAssembly>

I migliori saluti

Ho avuto un problema con questo in un progetto NUnit 2.6.4 rivolto a dotnet framework 4.6.2. Mi sono imbattuto in System.Runtime FileNotFoundquell'errore cercando di usare Humanizer .

Ho corretto il mio errore installando NetStandard.Library nel mio progetto di unit test.

Abbiamo scoperto che AutoGenerateBindingRedirectspotrebbe essere la causa di questo problema.

Osservato: lo stesso progetto mirava net45ed netstandard1.5è stato costruito con successo su una macchina e non è riuscito a costruire sull'altra. Le macchine avevano diverse versioni del framework installate (4.6.1 - successo e 4.7.1 - fallimento). Dopo aver aggiornato il framework sulla prima macchina alla 4.7.1, anche la build non è riuscita.

Error Message:
 System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
  ----> System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Auto binding redirectsè una caratteristica di .net 4.5.1. Ogni volta che nuget rileva che il progetto fa riferimento in modo transitorio a versioni diverse dello stesso assembly, genererà automaticamente il file di configurazione nella directory di output reindirizzando tutte le versioni alla versione più alta richiesta.

Nel nostro caso è stato riassociato tutte le versioni di System.Runtimea Version=4.1.0.0. .net 4.7.1viene fornito con una 4.3.0.0versione di runtime. Quindi l'associazione di reindirizzamento era mappata a una versione che non era disponibile in una versione contemporanea di framework.

Il problema è stato risolto disabilitando i reindirizzamenti di binding automatico per la destinazione 4.5 e lasciandolo solo per .net core.

<PropertyGroup Condition="'$(TargetFramework)' == 'net45'">
  <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
</PropertyGroup>

Questo problema ha molte cause ... nel mio caso il problema era che nel mio web.config c'era un tag che aggiungeva l'assembly System.Runtime:

<assemblies>
    <add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>

ma un pacchetto ha anche aggiunto lo stesso assembly come dipendenza con un'altra versione:

<package id="System.Runtime" version="4.3.0" targetFramework="net47" />

la rimozione del tag "add assembly" dal mio web.config ha risolto il problema.

Sembra che il problema sia causato quando c'è un conflitto di versione tra packages.config e app.config. In app.config hai reindirizzamenti dell'associazione di assembly generati automaticamente da una cosa chiamata "AutoGenerateBindingRedirects". Se abilitato ogni volta che scarichi il pacchetto nuget, oltre a creare una nuova voce in packages.config, aggiungerà queste informazioni di reindirizzamento del binding ad app.config, qual è lo scopo di questo è spiegato qui: Reindirizzamento dell'assembly Binding: come e perché?

Lì puoi leggere cosa ha scritto l'utente @Evk:

Perché sono necessari reindirizzamenti vincolanti? Supponiamo di avere l'applicazione A che fa riferimento alla libreria B e anche alla libreria C della versione 1.1.2.5. La libreria B a sua volta fa riferimento anche alla libreria C, ma della versione 1.1.1.0. Ora abbiamo un conflitto, perché non è possibile caricare versioni diverse dello stesso assembly in fase di esecuzione. Per risolvere questo conflitto è possibile utilizzare il reindirizzamento dell'associazione, solitamente alla nuova versione

Quindi, RISOLUZIONE RAPIDA: rimuovere tutte le voci in app.config.

Nel mio caso solo facendo quel programma ha iniziato a funzionare, ma probabilmente funzionerà solo se non si hanno conflitti di versione dello stesso assembly in fase di esecuzione.

In caso di conflitto di questo tipo, è necessario correggere questi numeri di versione in app.config in modo che corrispondano alle versioni effettivamente utilizzate degli assembly, ma il processo manuale è doloroso, quindi suggerisco di generarli di nuovo automaticamente aprendo la Console di Gestione pacchetti ed eseguire la reinstallazione dei pacchetti digitando Update-Package -reinstall

Sono finito in questa situazione più volte con il mio sito web .NET 4.6.1. Ho creato il problema ogni volta che ho aggiunto un riferimento a un progetto .NET Core separato. Al momento della creazione, Visual Studio mi ha avvisato correttamente che tali riferimenti incrociati non sono validi e ho eliminato rapidamente il riferimento al progetto. Il progetto è stato costruito bene dopo, ma l'errore System.Runtime è apparso durante l'accesso al sito Web e si è rifiutato di andare via.

La correzione ogni volta era debole ma efficace: ho cancellato la directory del progetto e l'ho scaricata di nuovo dal controllo del codice sorgente. Anche se non c'era differenza tra prima e dopo, sono stato in grado di realizzare il progetto e accedere alla pagina senza lamentele.

Ci siamo imbattuti proprio ora in un progetto di Unit Test dopo aver aggiunto MsTest V2 tramite Nuget. Rinominare app.config (rimuovendolo così efficacemente) ha fatto il trucco per me.

Dopo aver letto tutti i post di cui sopra, non sono ancora sicuro del perché, mi dispiace!

Ho risolto il problema rimuovendo il pacchetto Nuget System.Runtimee reinstallandolo

In app.config o web.config aggiungere

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

Ho avuto un progetto con lo stesso problema, l'ho risolto cambiando versione dotnet core da 2.2 a 2.0, se il problema è rimasto, prova questa soluzione

Prima di eseguire gli unit test, è sufficiente rimuovere i tag di runtime dal file app.config. Il problema sarà risolto.

Ho avuto un problema simile in VS 2017 15.45: ho scoperto che quando ho controllato che, anche se il progetto è stato compilato ed eseguito, è venuto fuori un'eccezione system.IO.FileNotFoundException per quanto riguarda System.Runtime quando ho provato ad accedere agli oggetti TPL Dataflow.

Quando ho controllato i progetti nella soluzione, a uno di essi (quello in alto) mancava il pacchetto System.Runtime utilizzato dai progetti sottostanti. Una volta installato da Nuget, tutto ha funzionato correttamente.

Ho provato tutte le soluzioni qui, ma senza successo. Alla fine, l'ho risolto aprendo il nuovo file csproj e aggiunto manualmente la seguente sezione:

<Reference Include="System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<HintPath>..\packages\System.Runtime.4.3.0\lib\net462\System.Runtime.dll</HintPath>
</Reference>

Sto usando ASP.Net CORE 2.1 e ho ricevuto questo errore quando ho eseguito selezionando un .csproj da un elenco di circa 40 in un grande repository. Quando ho aperto il file csproj individualmente, l'errore è stato risolto. Qualcosa con il modo in cui è stato avviato il programma era diverso quando è stato aperto csproj.

Risolvo questo problema passando da .NET 4.7.2 => .NET 4.5.2 e poi ritorno a 472. Quindi in alcuni casi questo errore si verifica perché il gestore di pacchetti non è in grado di risolvere le dipendenze

Se funziona in precedenza, dovrebbe esserci una modifica di App.config. Undo App.config ha funzionato per me.

Ho anche attraversato questo errore e ho condiviso come mi sono sbarazzato di esso.

Nel mio caso la riga sottostante esisteva in web.config del progetto webapi ma non c'era il riferimento al pacchetto nel file package.config.

Codice in Web.config nel progetto Webapi

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.3.0" />
</dependentAssembly>

Codice I Aggiunto nel file packages.config nel progetto web api Prima della chiusura dell'elemento.

<package id="System.Runtime" version="4.3.0" targetFramework="net461" />

Un'altra soluzione ha funzionato nel mio caso:

Un altro Sicuramente breve che potrebbe funzionare nel caso in cui hai copiato il progetto su un altro sistema informatico che potrebbe avere versioni del pacchetto leggermente diverse, puoi provare a cambiare la versione dell'assembly alla versione fornita per errore sul sito Web / webapi quando lo esegui. Come in questo caso, come indicato nella domanda La versione necessaria è '4.1.0.0' quindi prova semplicemente a cambiare la versione corrente in web.config alla versione mostrata per errore come di seguito

Errore:

Could not load file or assembly 'System.Runtime, Version=4.1.0.0' or one of its dependencies

Ho riscontrato questo errore durante la creazione di una funzione di Azure (con un trigger di coda, dovrebbe fare la differenza)

Il problema in questo caso era perché AzureFunctionsVersionera impostato su v2 anziché su v3. Per aggiornarlo tramite VS2019, scarica il progetto e modifica il file csproj. All'interno del PropertyGroupnodo, aggiungi / modifica quanto segue:

<PropertyGroup>
  <AzureFunctionsVersion>v3</AzureFunctionsVersion>
</PropertyGroup>