124 votes

Visual Studio 2017 - Impossible de charger le fichier ou l'assemblage '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 nUnit .Net 4.6.2.

J'obtiens l'erreur suivante...

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

J'ai essayé ce qui suit :

  1. Référence de la bibliothèque Std comme référence du projet. Erreur : me donne l'erreur précédente.
  2. Créer un pkg NuGet pour ma bibliothèque Std et y faire référence. Erreur : Le type est System.String, on attend System.String. Ceci est dû au fait que System.Runtime a fini par être référencé par le projet et qu'il contient des définitions pour tous les types standard.
  3. Référence NuGet pkg NetStandard.Library. Erreur : me donne la même erreur que # ("The type is System.String, expecting System.String"). NOTE : Avant de faire cela, j'ai effacé TOUS les paquets NuGet du projet, puis j'ai ajouté uniquement les paquets nUnit et NetStandard.Library (qui ont installé 45 autres paquets).

S'agit-il d'un bug ? Existe-t-il une solution de contournement ? Toute aide est la bienvenue.

103voto

typetrice Points 109

J'ai eu le même problème et aucune des solutions suggérées que j'ai trouvées n'a fonctionné. Ma solution pour ce problème était la suivante Vérifiez App.config et packages.config pour voir si les versions correspondent.

A 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 de app.config pour qu'elle corresponde à packages.config pour la nouvelle version :

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

0 votes

Ou ajoutez simplement la référence à votre web.config : stackoverflow.com/a/38603514/1145177

8 votes

J'ai tiré "4.3.0" de NuGet, mais pour une raison quelconque, VS insiste pour que je fasse référence à "4.1.2.0". Une solution similaire, avec un numéro de version différent, a fonctionné pour moi...

0 votes

J'ai eu le même problème que @DavidRogers dans un projet MSTest. La consolidation des différences entre app.config et packages.config a résolu le problème.

40voto

Tushar Points 426

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

Enfin, j'ai supprimé le <dependentAssembly> pour l'assemblage et le problème a disparu. Essayez donc de supprimer les éléments suivants 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 cadre .NET en 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 version de System.Linq dans app.config. Par conséquent, supprimez ou mettez à jour toutes les références Linq également pour vous débarrasser de ce problème.

4 votes

Chaque fois que je rencontre le problème mentionné par le PO, je supprime les informations System.Runtime dans le fichier .config et cela résout le problème. Je suis d'accord avec vous pour dire qu'il s'agit d'une solution potentiellement valable. Cela a tendance à se produire avec moi lorsque j'ajoute un paquet à partir de nuget.

0 votes

Cela a fonctionné pour moi. J'ai obtenu une erreur xunit System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.1.2.0 après avoir mis à jour mes projets vers 4.7.2

0 votes

Sur la base de votre réponse, j'ai vérifié mes paquets nuget et j'ai trouvé 'Google.protobuf' qui doit être consolidé entre mes projets, merci.

38voto

Cory Nelson Points 10540

Ce problème se produit lorsque vous faites référence à un projet .NET Standard à partir d'un projet .NET 4.x : aucune des références au paquet nuget du projet .NET Standard n'est intégrée comme dépendance.

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

<Project ToolsVersion="15.0">...

L'élément ci-dessous ne devrait plus être nécessaire, il a été corrigé vers VS 15.3 :

Il y avait un bug connu dans VS2017, notamment dans NuGet 4.0.

Pour contourner ce bogue, vous devez ouvrir le fichier .csproj de votre projet .NET 4.x et y ajouter cet extrait :

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

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

0 votes

Quelle mise à jour de Visual Studio 17 ? Pouvez-vous préciser la version ?

11 votes

J'ai toujours le problème dans la version 15.5.5 VS2017. Il semble qu'il y ait d'autres causes.

0 votes

Question : votre projet .NET 4.x utilise-t-il des références de paquet, ou utilise-t-il toujours packages.config ? Je me demande si la raison pour laquelle cela semble réglé pour moi est que je me suis débarrassé de packages.config.

31voto

Sheena Agrawal Points 404

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

11 votes

Une meilleure explication de la raison pour laquelle cela fonctionne serait utile.

0 votes

Le problème avec cette méthode est qu'à chaque fois que vous mettez à jour un paquet nuget ou que vous ajoutez un nouveau paquet nuget, il sera à nouveau ajouté.

17voto

Noffls Points 2236

J'ai résolu cette erreur en référençant le NetStandard.Library et ce qui suit app.config Fichier dans le projet NUnit.

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

Modifier

Si autre chose que System.Runtime , System.Reflection ou System.Runtime.InteropServices est manquant (par exemple System.Linq ), il suffit alors d'ajouter un nouveau dependentAssembly nœud.

Edit 2

Dans les nouvelles versions de Visual Studio (2017 15.8 je pense) il est possible que Studio crée le fichier app.config. Il suffit de vérifier le Génération automatique de redirections de liaison Case à cocher dans Propriétés du projet - Application . Auto-generate binding redirects

12 votes

Bizarrement, j'ai résolu le problème pour moi en enlever tous <dependentAssembly> nœuds pour System.Runtime..

1 votes

@MattBrewerton confirmé !

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X