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

Używam programu Visual Studio 2017 i próbuję utworzyć bibliotekę .Net Standard 1.5 i używać jej w projekcie testowym .Net 4.6.2 nUnit.

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

Nie można załadować pliku lub zestawu „System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jego zależności. System nie może odnaleźć określonego pliku.

Próbowałem następujących rzeczy:

1. Odwołanie do biblioteki standardowej jako odniesienie do projektu. Błąd: daje mi poprzedni błąd.
2. Utwórz pakiet NuGet dla mojej biblioteki Std i odwołaj się do tego. Błąd: typ to System.String, oczekuje się System.String. Dzieje się tak, ponieważ System.Runtime został przywołany przez projekt i ma definicje wszystkich standardowych typów.
3. Odwołanie do pakietu NuGet NetStandard.Library. Błąd: podaj ten sam błąd co # („Typ to System.String, oczekuje się 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 mile widziana.

Miałem ten sam problem i żadne sugerowane rozwiązania, które znalazłem, nie działały. Moim rozwiązaniem tego problemu było: Sprawdź App.config i packages.config, aby zobaczyć, czy wersje są zgodne.

Pierwotnie mój plik app.config zawierał:

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

Ale pakiet packages.config zawierał:

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

Zmodyfikowałem wpis app.config, aby pasował do packages.config dla nowej wersji:

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

Ten problem występuje podczas odwoływania się do projektu .NET Standard z projektu .NET 4.x: żadne odwołania do pakietu NuGet projektu .NET Standard nie są wprowadzane jako zależności.

Aby to naprawić, upewnij się, że plik csproj .NET 4.x wskazuje aktualne narzędzia do kompilacji (co najmniej 14):

<Project ToolsVersion="15.0">...

Poniższe nie powinno już być potrzebne, zostało naprawione około VS 15.3:

Wystąpił znany błąd w VS2017, szczególnie w NuGet 4.0.

Aby obejść ten błąd, musisz otworzyć plik .csproj dla projektu .NET 4.xi 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” - koniec z packages.config - ale stary potok 4.x nie był w pełni zaktualizowany w momencie uruchomienia VS2017. Powyższy fragment wydaje się „budzić” system kompilacji, aby poprawnie uwzględnić odwołania do pakietów z zależności.

Ostatnio napotykam ten problem i próbowałem wielu rzeczy wymienionych w tym wątku i innych. Dodałem odwołanie do "System.Runtime"pakietu dla menedżera pakietów NuGet app.config, poprawiłem redykcję powiązania i upewniłem się, że app.configipackage.config mają taką samą wersję do montażu. Jednak problem nie ustąpił.

W końcu usunąłem <dependentAssembly>tag do montażu i problem zniknął. Spróbuj więc usunąć następujące elementy z pliku 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>

Edycja: Po zaktualizowaniu platformy .NET do wersji 4.7.2 problem powrócił. Wypróbowałem powyższą sztuczkę, ale nie zadziałała. Po zmarnowaniu wielu godzin zdałem sobie sprawę, że problem występuje z powodu starego System.Linqodniesienia w pliku app.config. Dlatego usuń lub zaktualizuj wszystkie odniesienia Linq, aby pozbyć się tego problemu.

Zaufaj mi, nie żartuję. Usuń wszystkie zależności System.Runtime z pliku app.config i zacznie działać.

Rozwiązałem ten błąd, odwołując się do NetStandard.Library i następującego pliku app.config 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>

Edytować

Jeśli coś innego niż System.Runtime, System.Reflectionlub System.Runtime.InteropServicesbrakuje (np System.Linq), a następnie po prostu dodać nowydependentAssembly węzeł.

Edytuj 2

W nowych wersjach programu Visual Studio (myślę, że 2017 15.8) jest możliwe, że Studio tworzy plik app.config. Po prostu zaznacz pole wyboru Automatycznie generuj przekierowania powiązań we właściwościach projektu - aplikacja .

Edytuj 3

Automatyczne generowanie przekierowań powiązań nie działa dobrze z bibliotekami klas .NET. Dodanie poniższych wierszy do plików csproj rozwiązuje ten problem i zostanie wygenerowany działający plik .config dla biblioteki Classlibary.

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

Naprawiłem to, usuwając plik app.configz

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

wpisy.

app.config został automatycznie dodany (ale nie potrzebny) podczas refaktoryzacji

Ten problem występuje podczas odwoływania się do projektu .NET Standard z projektu .NET 4.x: żadne odwołania do pakietu NuGet projektu .NET Standard nie są wprowadzane jako zależności.

Rozwiązałem przez dodanie 4.3pakietu System.Runtime i NETStandard.Library i !! Używam narzędzia refaktoryzującego, aby sprawdzić wersję System.Runtime.dll, 4.1.1.1nie jest, 4.3a następnie dodaję bindingRedirect w .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>

Wiem, że jest już za późno, ale nie ma skutecznej odpowiedzi. Znalazłem odpowiedź z innej strony. Rozwiązałem problem, gdy usunąłem zależność zestawu System.Runtime. Usunąłem to.

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

Z poważaniem

Miałem problem z tym w projekcie NUnit 2.6.4 przeznaczonym dla platformy dotnet 4.6.2. Napotkałem ten System.Runtime FileNotFoundbłąd, próbując użyć Humanizera .

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

Odkryliśmy, że AutoGenerateBindingRedirectsmoże to powodować ten problem.

Zaobserwowano: ten sam projekt był przeznaczony net45i netstandard1.5został pomyślnie zbudowany na jednym komputerze, a nie został zbudowany na drugim. Maszyny miały zainstalowane różne wersje frameworka (4.6.1 - sukces i 4.7.1 - awaria). Po aktualizacji frameworka na pierwszym komputerze do 4.7.1 kompilacja również się nie powiodła.

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 redirectsjest cechą .net 4.5.1. Za każdym razem, gdy nuget wykryje, że projekt przejściowo odwołuje się do różnych wersji tego samego zestawu, automatycznie wygeneruje plik konfiguracyjny w katalogu wyjściowym, przekierowując wszystkie wersje do najwyższej wymaganej wersji.

W naszym przypadku było to ponowne wiązanie wszystkich wersji System.Runtimeto Version=4.1.0.0. .net 4.7.1statki z4.3.0.0 wersją środowiska wykonawczego. Więc przekierowanie było mapowaniem do wersji, która nie była dostępna we współczesnej wersji frameworka.

Problem został rozwiązany przez wyłączenie przekierowań automatycznego wiązania dla celu 4.5 i pozostawienie go tylko dla .net core.

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

Ten problem ma wiele przyczyn ... w moim przypadku problem polegał na tym, że w moim pliku web.config był tag dodający zestaw System.Runtime:

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

ale jeden pakiet dodał również ten sam zestaw jako zależność z inną wersją:

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

usunięcie tagu „add assembly” z mojego pliku web.config rozwiązało problem.

Wygląda na to, że problem jest spowodowany konfliktem wersji między packages.config i app.config. W app.config masz przekierowania wiązania zestawu automatycznie generowane przez coś o nazwie "AutoGenerateBindingRedirects". Po włączeniu za każdym razem, gdy pobierasz pakiet NuGet, dodatkowo, aby utworzyć nowy wpis w packages.config, dodać te informacje o przekierowaniu powiązania do app.config, jaki jest cel tego wyjaśniono tutaj: Przekierowanie powiązania zestawu : jak i dlaczego?

Tam możesz przeczytać, co napisał użytkownik @Evk:

Dlaczego w ogóle potrzebne są wiążące przekierowania? Załóżmy, że masz aplikację A, która odwołuje się do biblioteki B, a także do biblioteki C w wersji 1.1.2.5. Biblioteka B z kolei odwołuje się do biblioteki C, ale w wersji 1.1.1.0. Teraz mamy konflikt, ponieważ nie można załadować różnych wersji tego samego zestawu w czasie wykonywania. Aby rozwiązać ten konflikt, możesz użyć przekierowania powiązania, zwykle do nowej wersji

Więc QUICK FIX: Usuń wszystkie wpisy w app.config.

W moim przypadku samo wykonanie tego programu zaczęło działać, ale prawdopodobnie zadziała tylko wtedy, gdy nie masz żadnych konfliktów wersji tego samego zestawu w czasie wykonywania.

Jeśli masz taki konflikt, powinieneś naprawić te numery wersji w app.config, aby pasowały do ​​faktycznie używanych wersji zestawów, ale proces ręczny jest bolesny, więc sugeruję automatyczne wygenerowanie ich ponownie, otwierając Konsolę Menedżera pakietów i przeprowadź ponowną instalację pakietów, wpisując Update-Package -reinstall

Znalazłem się w takiej sytuacji kilka razy z moją witryną internetową .NET 4.6.1. Tworzyłem ten problem za każdym razem, gdy dodawałem odwołanie do oddzielnego projektu .NET Core. Podczas kompilacji program Visual Studio prawidłowo ostrzegł mnie, że takie odwołania między platformami są nieprawidłowe, i szybko usunąłem odwołanie do projektu. Po tym projekt dobrze się zbudował, ale podczas uzyskiwania dostępu do strony internetowej pojawił się błąd System.Runtime i odmówił jej usunięcia.

Poprawka za każdym razem była kiepska, ale skuteczna: usunąłem katalog projektu i pobrałem go ponownie z kontroli źródła. Chociaż nie było różnicy między przed i po, mogłem zbudować projekt i uzyskać dostęp do strony bez żadnych skarg.

Wpadłem na to właśnie teraz w projekcie testów jednostkowych po dodaniu MsTest V2 za pośrednictwem Nuget. Zmiana nazwy app.config (tak efektywne usunięcie) załatwiła mi sprawę.

Po przeczytaniu wszystkich powyższych postów nadal nie jestem pewien dlaczego, przepraszam!

Rozwiązałem problem, usuwając pakiet Nuget, System.Runtimea następnie instalując go ponownie

Do app.config lub web.config dodaj

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

Miałem projekt z tym samym problemem, rozwiązałem go ze zmianą wersji rdzenia dotnet z 2.2 na 2.0, jeśli twój problem pozostał, wypróbuj to rozwiązanie

Przed uruchomieniem testów jednostkowych wystarczy usunąć tagi środowiska wykonawczego z pliku app.config. Problem zostanie rozwiązany.

Podobny problem miałem w VS 2017 15.45 - stwierdziłem, że mimo że projekt został skompilowany i uruchomiony, pojawił się wyjątek system.IO.FileNotFoundException w odniesieniu do System.Runtime, gdy próbowałem uzyskać dostęp do obiektów TPL Dataflow.

Kiedy sprawdzałem projekty w rozwiązaniu, w jednym z nich (górnym) brakowało pakietu System.Runtime używanego przez podstawowe projekty. Po zainstalowaniu go z Nuget wszystko działało poprawnie.

Wypróbowałem tutaj wszystkie rozwiązania, ale bezskutecznie. Ostatecznie rozwiązałem to, otwierając nowy plik csproj i ręcznie dodając następującą sekcję:

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

Używam ASP.Net CORE 2.1 i otrzymałem ten błąd, gdy uruchomiłem, wybierając plik .csproj z listy około 40 w dużym repozytorium. Po indywidualnym otwarciu pliku csproj błąd został rozwiązany. Coś w sposobie uruchamiania programu było inne, gdy otwierano csproj.

Rozwiązuję ten problem, przełączając się z .NET 4.7.2 => .NET 4.5.2, a następnie przełączam się z powrotem na 472. W niektórych przypadkach ten błąd występuje, ponieważ menedżer pakietów nie może rozwiązać zależności

Jeśli wcześniej działało, powinna nastąpić zmiana App.config. Cofnij App.config działał dla mnie.

Przeszedłem również przez ten błąd i podzieliłem się tym, jak się do niego pozbyłem.

W moim przypadku poniższa linia istniała w web.config projektu webapi, ale nie było odniesienia do pakietu w pliku package.config.

Kod w Web.config w 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>

Kod I Dodany w pliku packages.config w projekcie web api Przed zamknięciem elementu.

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

Inne rozwiązanie zadziałało w moim przypadku:

Kolejny pewny skrót, który może zadziałać w przypadku skopiowania projektu do innego systemu komputerowego, który może mieć niewiele różnych wersji pakietu, możesz spróbować zmienić wersję zestawu na wersję podaną błędnie na stronie internetowej / webapi podczas jej uruchamiania. Jak w tym przypadku jak podano w pytaniu Wymagana wersja to 4.1.0.0 więc po prostu spróbuj zmienić aktualną wersję w web.config na wersję pokazaną błędnie jak poniżej

Błąd:

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

Wystąpił ten błąd podczas tworzenia funkcji platformy Azure (z wyzwalaczem kolejki, jeśli to ma znaczenie)

Problem w tym przypadku był taki, że AzureFunctionsVersionustawiono v2 zamiast v3. Aby zaktualizować go przez VS2019, zwolnij projekt, a następnie edytuj plik csproj. W PropertyGroupwęźle dodaj / edytuj następujące elementy:

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