Visual Studio 2017 - Nie można załadować pliku lub zestawu "System.Runtime, Version = 4.1.0.0" lub jednej z jego zależności

Question

Używam programu Visual Studio 2017 i próbuję utworzyć bibliotekę .Net Standard 1.5 i użyć go w a .Net 4.6.2 nUnit projekt testowy.

otrzymuję następujący błąd ...

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.

Próbowałem następujące:

1. referencyjny Std biblioteki jako odniesienie projektu. Błąd: daje mi poprzedni błąd.
2. Utwórz paczkę NuGet dla mojej biblioteki Std i odniesienie do niej. Błąd: Typ jest System.String, oczekując System.String. Dzieje się tak, ponieważ System.Runtime zakończyło się odwoływaniem do projektu i ma definicje dla wszystkich standardowych typów.
3. Odniesienie NuGet pkg NetStandard.Library. Błąd: daj mi ten sam błąd co # ("Typ to System.String, oczekujący System.String"). UWAGA: Zanim to zrobiłem, wyczyściłem wszystkie pakiety NuGet z projektu, a następnie dodałem tylko pakiety nUnit i NetStandard.Library (które zainstalowały 45 innych pakietów).

Czy to błąd? Czy jest w pobliżu praca? Każda pomoc jest doceniana.

Answer 1

To jest known bug w VS2017, w szczególności w NuGet 4.0.

Aby obejść ten błąd, musisz otworzyć plik .csproj dla projektu 4.x .NET i dodać ten fragment:

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

Nuget 4.x niesie ze sobą " odwołanie do pakietu "- nie więcej pakietów.config. Niestety jest on teraz obsługiwany tylko w projektach .NET Core i .NET Standard.

To, co się stało, to że kiedy odwołujesz się do projektu .NET Standard z projektu .NET 4.x, żadne odwołania do projektu projektu .NET Standard nie są dostarczane jako zależności. Powyższy fragment wydaje się "budzić" system budowania, aby poprawnie je uwzględnić.

Edytuj: wygląda na to, że zostało rozwiązane w aktualizacji 15.3. To obejście nie powinno już być potrzebne

Answer 2

Miałem problem z tym w projekcie NUnit 2.6.4 targetowania ramek dotnet 4.6.2. Wpadłem na ten błąd System.Runtime FileNotFound próbując użyć Humanizer.

Naprawiłem błąd, instalując NetStandard.Library w moim projekcie testu jednostkowego.

Answer 3

postanowiłem ten błąd przez odwołanie do NetStandard.Library oraz następujące app.config Plik w 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> 

Edit

Jeśli cokolwiek innego niż System.Runtime, System.Reflection lub System.Runtime.InteropServices brakuje (np System.Linq), a następnie po prostu dodać nowy dependentAssembly węzła.

Answer 4

Kilka razy znalazłem się w tej sytuacji z moją witryną .NET 4.6.1. Stworzyłem problem za każdym razem, gdy dodałem odwołanie do oddzielnego projektu .NET Core. Podczas budowania Visual Studio poprawnie powiadomiło mnie, że takie odwołania między ramami są nieprawidłowe i szybko usunąłem odniesienie do projektu. Projekt został zbudowany dobrze po tym, ale błąd System.Runtime pojawił się podczas uzyskiwania dostępu do strony internetowej i nie chciał odejść.

Poprawka za każdym razem była lame, ale skuteczna: usunąłem katalog projektu i ponownie wczytałem go ze sterowania źródłowego. Mimo że nie było różnicy między przed i po, udało mi się zbudować projekt i uzyskać dostęp do strony bez skarg.

Answer 5

Miałem podobny problem w VS 2017 15.45 - Znalazłem, gdy sprawdziłem, że pomimo kompilacji projektu i uruchomienia go pojawił się wyjątek system.IO.FileNotFoundException w odniesieniu do System.Runtime, gdy próbowałem uzyskać dostęp do TPL Dataflow obiekty.

Po sprawdzeniu projektów w roztworze, w jednym z nich (na górze) brakowało pakietu System.Runtime używanego przez podstawowe projekty. Po zainstalowaniu go z Nuget wszystko działało poprawnie.

Answer 6

Miałem ten sam problem i żadne sugerowane rozwiązania, które znalazłem, nie zadziałały. Moje rozwiązanie dla tego problemu: Sprawdź App.config i packages.config, aby sprawdzić, czy wersje są zgodne.

Originally my app.config contained: 

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

But the packages.config contained: 

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

I modified the app.config entry to match packages.config for the 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> 

Po zmianie problem został rozwiązany.