Visual Studio 2017 - Impossible de charger le fichier ou l'assembly 'System.Runtime, Version = 4.1.0.0' ou l'une de ses dépendances

J'utilise Visual Studio 2017 et j'essaie de créer une bibliothèque .Net Standard 1.5 et de l'utiliser dans un projet de test .Net 4.6.2 nUnit.

Je reçois l'erreur suivante...

Impossible de charger le fichier ou l'assembly 'System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.

J'ai essayé ce qui suit:

1. Référence bibliothèque Std comme référence de projet. Erreur: me donne l'erreur précédente.
2. Créez un pkg NuGet pour ma bibliothèque Std et référencez-le. Erreur: le type est System.String, en attendant System.String. En effet, System.Runtime a fini par être référencé par le projet et il a des définitions pour tous les types standard.
3. Référence NuGet pkg NetStandard.Library. Erreur: donnez-moi la même erreur que # ("Le type est System.String, attend System.String"). REMARQUE: avant cela, j'ai effacé TOUS les packages NuGet du projet, puis ajouté uniquement les packages nUnit et NetStandard.Library (qui ont installé 45 autres packages).

Est-ce un bug? Y at-il un travail autour? Toute aide est appréciée.

J'ai eu le même problème et aucune solution suggérée que j'ai trouvée fonctionnait. Ma solution à ce problème était: Vérifiez App.config et packages.config pour voir si les versions correspondent.

À l'origine, mon app.config contenait:

<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>

Mais le packages.config contenait:

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

J'ai modifié l'entrée app.config pour qu'elle corresponde à packages.config pour 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>

Après le changement, le problème a été résolu.

Ce problème se produit lorsque vous référencez un projet .NET Standard à partir d'un projet .NET 4.x: aucune des références de package nuget du projet .NET Standard n'est importée en tant que dépendances.

Pour résoudre ce problème, vous devez vous assurer que votre fichier .NET 4.x csproj pointe vers les outils de construction actuels (au moins 14):

<Project ToolsVersion="15.0">...

Ce qui suit ne devrait plus être nécessaire, il a été corrigé autour de VS 15.3:

Il y avait un bogue connu dans VS2017, en particulier dans NuGet 4.0.

Pour contourner le bogue, vous devrez ouvrir le fichier .csproj pour votre projet .NET 4.x et ajouter cet extrait de code:

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

NuGet 4.x apporte avec lui la "référence de package" - plus de packages.config - mais l'ancien pipeline 4.x n'était pas entièrement mis à jour au moment du lancement de VS2017. L'extrait de code ci-dessus semble «réveiller» le système de construction pour inclure correctement les références de paquet à partir des dépendances.

J'ai rencontré ce problème récemment et j'ai essayé de nombreuses choses mentionnées dans ce fil et dans d'autres. J'ai ajouté référence paquet pour "System.Runtime"par gestionnaire de paquets NuGet, a fixé les redicts de liaison dans app.config, et assurez - vous app.configet package.configavoir la même version pour l'assemblage. Cependant, le problème persistait.

Enfin, j'ai enlevé l' <dependentAssembly>étiquette de l'assemblage et le problème a disparu. Alors, essayez de supprimer ce qui suit dans votre 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>

Edit: Après avoir mis à jour le framework .NET vers 4.7.2, le problème a refait surface. J'ai essayé l'astuce ci-dessus mais cela n'a pas fonctionné. Après avoir perdu de nombreuses heures, j'ai réalisé que le problème se produisait à cause d'une ancienne System.Linqréférence dans app.config. Par conséquent, supprimez ou mettez à jour toutes les références Linq également pour éliminer ce problème.

Croyez-moi, je ne plaisante pas. Supprimez toutes les dépendances System.Runtime de votre app.config et il commencera à fonctionner.

J'ai résolu cette erreur en référençant la NetStandard.Library et le fichier app.config suivant dans le 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>

Éditer

Si quelque chose d'autre que System.Runtime, System.Reflectionou System.Runtime.InteropServicesest manquant (par exemple System.Linq), alors ajoutez simplement un nouveau dependentAssemblynœud.

Modifier 2

Dans les nouvelles versions de Visual Studio (2017 15.8 je pense), il est possible que Studio crée le fichier app.config. Cochez simplement la case à cocher Générer automatiquement les redirections de liaison dans Propriétés du projet - Application .

Modifier 3

La génération automatique de redirections de liaison ne fonctionne pas correctement avec les bibliothèques de classes .NET. L'ajout des lignes suivantes aux fichiers csproj résout ce problème et un fichier .config fonctionnel pour la bibliothèque de classes sera généré.

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

Je l'ai corrigé en supprimant mon app.configavec

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

entrées.

app.config a été automatiquement ajouté (mais pas nécessaire) lors de la refactorisation

Ce problème se produit lorsque vous référencez un projet .NET Standard à partir d'un projet .NET 4.x: aucune des références de package nuget du projet .NET Standard n'est importée en tant que dépendances.

J'ai résolu en ajoutant le 4.3package System.Runtime et NETStandard.Library et !! important !! J'utilise l'outil de refactor pour rechercher la version System.Runtime.dll, ce n'est 4.1.1.1pas le cas 4.3, puis j'ajoute un bindingRedirect dans .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>

il est trop tard je sais, mais il n'y a pas de réponse réussie. J'ai trouvé la réponse sur un autre site Web. J'ai résolu le problème lorsque je supprimais la dépendance d'assemblage System.Runtime. J'ai supprimé ceci.

<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>

Meilleures salutations

J'ai eu un problème avec cela dans un projet NUnit 2.6.4 ciblant le framework dotnet 4.6.2. J'ai rencontré cette System.Runtime FileNotFounderreur en essayant d'utiliser Humanizer .

J'ai corrigé mon erreur en installant NetStandard.Library dans mon projet de test unitaire.

Nous avons constaté que cela AutoGenerateBindingRedirectspouvait causer ce problème.

Observé: le même projet ciblant net45et a netstandard1.5été construit avec succès sur une machine et n'a pas réussi à s'appuyer sur l'autre. Les machines avaient différentes versions du framework installées (4.6.1 - succès et 4.7.1 - échec). Après la mise à niveau du framework sur la première machine vers 4.7.1, la construction a également échoué.

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 redirectsest une caractéristique de .net 4.5.1. Chaque fois que nuget détecte que le projet fait référence de manière transitoire à différentes versions du même assembly, il génère automatiquement le fichier de configuration dans le répertoire de sortie en redirigeant toutes les versions vers la version requise la plus élevée.

Dans notre cas, il s'agissait de relier toutes les versions de System.Runtimeà Version=4.1.0.0. .net 4.7.1est livré avec une 4.3.0.0version d'exécution. La liaison de redirection était donc mappée vers une version qui n'était pas disponible dans une version contemporaine de framework.

Le problème a été résolu en désactivant les redirections de liaison automatique pour la cible 4.5 et en les laissant uniquement pour .net core.

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

Ce problème a de nombreuses causes ... dans mon cas, le problème était qu'il y avait dans mon web.config une balise ajoutant l'assembly System.Runtime:

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

mais un package a également ajouté le même assembly que la dépendance avec une autre version:

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

la suppression de la balise "add assembly" de mon web.config a résolu le problème.

On dirait que le problème est causé lorsqu'il y a un conflit de version entre packages.config et app.config. Dans app.config, vous avez des redirections de liaison d'assembly générées automatiquement par une chose appelée "AutoGenerateBindingRedirects". Lorsqu'il est activé chaque fois que vous téléchargez le package nuget, il ajoutera, en plus de créer une nouvelle entrée dans packages.config, ces informations de redirection de liaison à app.config, quel en est le but est expliqué ici: Redirection de liaison d'assembly: comment et pourquoi?

Vous pouvez y lire ce que l'utilisateur @Evk a écrit:

Pourquoi des redirections de liaison sont-elles nécessaires? Supposons que vous ayez l'application A qui référence la bibliothèque B, ainsi que la bibliothèque C de la version 1.1.2.5. La bibliothèque B fait également référence à la bibliothèque C, mais de la version 1.1.1.0. Nous avons maintenant un conflit, car vous ne pouvez pas charger différentes versions du même assembly lors de l'exécution. Pour résoudre ce conflit, vous pouvez utiliser la redirection de liaison, généralement vers la nouvelle version

Donc, CORRECTIF RAPIDE: supprimez toutes les entrées dans app.config.

Dans mon cas, juste en faisant ce programme a commencé à fonctionner, mais cela ne fonctionnera probablement que si vous n'avez aucun conflit de version du même assemblage au moment de l'exécution.

Si vous avez un tel conflit, vous devez corriger ces numéros de version dans app.config pour qu'ils correspondent aux versions réellement utilisées des assemblys, mais le processus manuel est douloureux, je suggère donc de les générer à nouveau automatiquement en ouvrant la console du gestionnaire de packages et de réinstaller les packages en tapant Update-Package -reinstall

Je me suis retrouvé dans cette situation plusieurs fois avec mon site Web .NET 4.6.1. J'ai créé le problème à chaque fois que j'ai ajouté une référence à un projet .NET Core distinct. Lors de la création, Visual Studio m'a correctement alerté que de telles références inter-framework ne sont pas valides et j'ai rapidement supprimé la référence de projet. Le projet s'est bien construit après cela, mais l'erreur System.Runtime est apparue lors de l'accès au site Web et a refusé de disparaître.

Le correctif à chaque fois était nul mais efficace: j'ai supprimé le répertoire du projet et je l'ai retéléchargé à partir du contrôle de code source. Même s'il n'y avait aucune différence entre avant et après, j'ai pu construire le projet et accéder à la page sans aucune plainte.

Ran dans ce tout à l'heure dans un projet de test unitaire après avoir ajouté MsTest V2 via Nuget. Renommer app.config (afin de le supprimer efficacement) a fait l'affaire pour moi.

Après avoir lu tous les articles ci-dessus, je ne sais toujours pas pourquoi, désolé!

J'ai résolu le problème en supprimant le package Nuget System.Runtime, puis en le réinstallant

Dans app.config ou web.config ajouter

<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>

J'ai eu un projet avec le même problème, je l'ai résolu en changeant la version dotnet core de 2.2 à 2.0, si votre problème persiste, essayez cette solution

Avant d'exécuter les tests unitaires, supprimez simplement les balises d'exécution du fichier app.config. Le problème sera résolu.

J'ai eu un problème similaire dans VS 2017 15.45 - J'ai trouvé quand j'ai vérifié que même si le projet compilé et exécuté, il a généré une exception system.IO.FileNotFoundException en ce qui concerne System.Runtime lorsque j'ai essayé d'accéder aux objets TPL Dataflow.

Lorsque j'ai vérifié les projets dans la solution, l'un d'entre eux (le premier) manquait le package System.Runtime utilisé par les projets sous-jacents. Une fois que je l'ai installé à partir de Nuget, tout a fonctionné correctement.

J'ai essayé toutes les solutions ici, mais en vain. Finalement, je l'ai résolu en ouvrant le nouveau fichier csproj et en ajoutant manuellement la section suivante:

<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>

J'utilise ASP.Net CORE 2.1 et j'ai eu cette erreur lorsque j'ai couru en sélectionnant un .csproj dans une liste d'environ 40 dans un grand dépôt. Lorsque j'ai ouvert le fichier csproj individuellement, l'erreur a été résolue. Quelque chose avec la façon dont le programme a été lancé était différent lorsque le csproj a été ouvert.

Je résous ce problème en passant de .NET 4.7.2 => .NET 4.5.2, puis je reviens à 472. Donc, dans certains cas, cette erreur se produit car le gestionnaire de packages ne peut pas résoudre les dépendances

Si cela fonctionne précédemment, il devrait y avoir un changement App.config. Annuler App.config a fonctionné pour moi.

J'ai également traversé cette erreur et partagé comment je m'en suis débarrassé.

Dans mon cas, la ligne ci-dessous existait dans web.config du projet webapi mais il n'y avait pas de référence de package dans le fichier package.config.

Code dans Web.config dans Webapi Project

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

Code que j'ai ajouté dans le fichier packages.config dans le projet API Web Avant la fermeture de l'élément.

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

Une autre solution a fonctionné dans mon cas:

Un autre court métrage sûr qui peut fonctionner au cas où vous copiez le projet sur un autre système informatique qui peut avoir des versions de package peu différentes que vous pouvez essayer de changer la version de l'assembly en version donnée par erreur sur le site Web / webapi lorsque vous l'exécutez. Comme dans ce cas, comme indiqué en question, la version nécessaire est `` 4.1.0.0 '', alors essayez simplement de changer la version actuelle de web.config en version affichée par erreur comme ci-dessous

Erreur:

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

Cette erreur s'est produite lors de la création d'une fonction Azure (avec un déclencheur de file d'attente, si cela devait faire une différence)

Le problème dans ce cas était dû au fait que le AzureFunctionsVersionétait défini sur v2 au lieu de v3. Pour le mettre à jour via VS2019, déchargez le projet puis éditez le fichier csproj. Dans le PropertyGroupnœud, ajoutez / modifiez les éléments suivants:

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