Visual Studio 2017 - Não foi possível carregar o arquivo ou assembly 'System.Runtime, Version = 4.1.0.0' ou uma de suas dependências

Estou usando o Visual Studio 2017 e estou tentando criar uma biblioteca .Net Standard 1.5 e usá-la em um projeto de teste .Net 4.6.2 nUnit.

Eu estou recebendo o seguinte erro...

Não foi possível carregar o arquivo ou assembly 'System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado.

Eu tentei o seguinte:

1. Biblioteca de referência Std como referência do projeto. Erro: me dá o erro anterior.
2. Crie um pacote NuGet para minha biblioteca Std e faça referência a ele. Erro: o tipo é System.String, esperando System.String. Isso porque System.Runtime acabou sendo referenciado pelo projeto e possui definições para todos os tipos padrão.
3. Consulte o pacote NuGet NetStandard.Library. Erro: forneça o mesmo erro de # ("O tipo é System.String, esperando System.String"). NOTA: Antes de fazer isso, limpei TODOS os pacotes NuGet do projeto e, em seguida, adicionei apenas os pacotes nUnit e NetStandard.Library (que instalou 45 outros pacotes).

Isso é um inseto? Existe uma solução alternativa? Qualquer ajuda é apreciada.

Eu tive o mesmo problema e nenhuma solução sugerida que achei funcionou. Minha solução para esse problema foi: Verifique App.config e packages.config para ver se as versões correspondem.

Originalmente, meu app.config continha:

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

Mas o packages.config continha:

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

Modifiquei a entrada app.config para corresponder a packages.config para a 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>

Após a mudança, o problema foi resolvido.

Esse problema ocorre quando você faz referência a um projeto .NET Standard a partir de um projeto .NET 4.x: nenhuma das referências do pacote nuget do projeto .NET Standard são trazidas como dependências.

Para corrigir isso, você precisa garantir que seu arquivo .NET 4.x csproj esteja apontando para as ferramentas de compilação atuais (pelo menos 14):

<Project ToolsVersion="15.0">...

O seguinte não deve mais ser necessário, ele foi corrigido em torno do VS 15.3:

Havia um bug conhecido no VS2017, especificamente no NuGet 4.0.

Para contornar o bug, você precisará abrir o arquivo .csproj do seu projeto .NET 4.x e adicionar este snippet:

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

NuGet 4.x traz consigo a "referência de pacote" - sem mais packages.config - mas o antigo pipeline 4.x não foi totalmente atualizado no momento do lançamento do VS2017. O trecho acima parece "despertar" o sistema de compilação para incluir corretamente as referências de pacote das dependências.

Encontrei esse problema recentemente e tentei muitas coisas mencionadas neste tópico e em outros. Eu adicionei referência pacote para "System.Runtime"pelo gerenciador de pacotes NuGet, fixa as redicts ligação em app.confige certifique-se de que app.confige package.configter a mesma versão para a montagem. No entanto, o problema persistiu.

Por fim, removi a <dependentAssembly>etiqueta da montagem e o problema desapareceu. Portanto, tente remover o seguinte em seu 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>

Editar: Depois de atualizar o .NET framework para 4.7.2, o problema reapareceu. Tentei o truque acima, mas não funcionou. Depois de perder muitas horas, percebi que o problema estava ocorrendo por causa de uma System.Linqreferência antiga no app.config. Portanto, remova ou atualize todas as referências do Linq também para se livrar desse problema.

Acredite em mim, não estou brincando. Remova todas as dependências System.Runtime de seu app.config e ele começará a funcionar.

Resolvi esse erro fazendo referência ao NetStandard.Library e ao seguinte arquivo app.config no 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>

Editar

Se qualquer coisa diferente de System.Runtime, System.Reflectionou System.Runtime.InteropServicesestá faltando (por exemplo System.Linq), em seguida, basta adicionar um novodependentAssembly nó.

Editar 2

Nas novas versões do Visual Studio (2017 15.8 eu acho), é possível que o Studio crie o arquivo app.config. Apenas marque a caixa de seleção Gerar automaticamente redirecionamentos de ligação em Propriedades do projeto - Aplicativo .

Editar 3

A geração automática de redirecionamentos de vinculação não funciona bem com as bibliotecas de classes .NET. Adicionar as seguintes linhas aos arquivos csproj resolve isso e um arquivo .config de trabalho para o Classlibary será gerado.

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

Consertei excluindo meu app.configcom

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

entradas.

app.config foi adicionado automaticamente (mas não necessário) durante a refatoração

Esse problema ocorre quando você faz referência a um projeto .NET Standard a partir de um projeto .NET 4.x: nenhuma das referências do pacote nuget do projeto .NET Standard são trazidas como dependências.

4.3Resolvi adicionando o pacote System.Runtime e NETStandard.Library e !! importante !! Eu uso a ferramenta de refatoração para pesquisar a versão System.Runtime.dll, 4.1.1.1não é 4.3e, em seguida, adiciono um bindingRedirect em .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>

já é tarde demais, eu sei, porém não há uma resposta com sucesso. Eu encontrei a resposta em outro site. Corrigi o problema ao excluir a dependência de montagem System.Runtime. Eu apaguei isso.

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

Cumprimentos

Tive um problema com isso em um projeto NUnit 2.6.4 visando a estrutura dotnet 4.6.2. Encontrei esse System.Runtime FileNotFounderro ao tentar usar o Humanizer .

Corrigi meu erro instalando o NetStandard.Library em meu projeto de teste de unidade.

Nós descobrimos que AutoGenerateBindingRedirects pode estar causando esse problema.

Observado: o mesmo projeto tem como alvo net45e netstandard1.5foi construído com sucesso em uma máquina e falhou na construção na outra. As máquinas tinham diferentes versões do framework instaladas (4.6.1 - sucesso e 4.7.1 - falha). Após atualizar o framework na primeira máquina para 4.7.1, a compilação também falhou.

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 é uma característica de .net 4.5.1 . Sempre que o nuget detecta que o projeto está fazendo referência transitivamente a diferentes versões do mesmo assembly, ele irá gerar automaticamente o arquivo de configuração no diretório de saída, redirecionando todas as versões para a versão mais alta necessária.

Em nosso caso, foi religando todas as versões de System.Runtimepara Version=4.1.0.0. .net 4.7.1vem com uma 4.3.0.0versão do tempo de execução. Portanto, a vinculação de redirecionamento estava mapeando para uma versão que não estava disponível em uma versão contemporânea do framework.

O problema foi corrigido com a desativação dos redirecionamentos de ligação automática para o destino 4.5 e deixando-o apenas para o núcleo .net.

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

Esse problema tem muitas causas ... no meu caso o problema era que no meu web.config uma tag adicionando o assembly System.Runtime:

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

mas um pacote também adicionou o mesmo assembly como dependência com outra versão:

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

remover a tag "add assembly" do meu web.config resolveu o problema.

Parece que o problema é causado quando há conflito de versão entre packages.config e app.config. Em app.config, você tem redirecionamentos de associação de assembly gerados automaticamente por algo chamado "AutoGenerateBindingRedirects". Quando habilitado cada vez que você baixar o pacote nuget, ele irá, além de fazer uma nova entrada em packages.config, adicionar essas informações de redirecionamento de vinculação a app.config. Qual é o propósito disso é explicado aqui: Redirecionamento de vinculação de assembly: como e por quê?

Lá você pode ler o que o usuário @Evk escreveu:

Por que os redirecionamentos de ligação são necessários? Suponha que você tenha o aplicativo A que faz referência à biblioteca B e também à biblioteca C da versão 1.1.2.5. A biblioteca B, por sua vez, também faz referência à biblioteca C, mas da versão 1.1.1.0. Agora temos um conflito, porque você não pode carregar versões diferentes do mesmo assembly em tempo de execução. Para resolver este conflito, você pode usar o redirecionamento de ligação, geralmente para a nova versão

Portanto, CORREÇÃO RÁPIDA: Remova todas as entradas em app.config.

No meu caso, apenas fazendo esse programa começou a funcionar, mas provavelmente funcionará apenas se você não tiver nenhum conflito de versão do mesmo assembly em tempo de execução.

Se você tiver esse conflito, deve corrigir esses números de versão em app.config para corresponder às versões realmente usadas dos assemblies, mas o processo manual é doloroso, então sugiro gerá-los automaticamente novamente abrindo o Console do gerenciador de pacotes e executar a reinstalação dos pacotes digitando Update-Package -reinstall

Acabei nessa situação várias vezes com meu site .NET 4.6.1. Eu criei o problema sempre que adicionei uma referência a um projeto .NET Core separado. Durante a construção, o Visual Studio alertou-me corretamente de que essas referências de cross-framework são inválidas e eu rapidamente excluí a referência do projeto. O projeto foi construído bem depois disso, mas o erro System.Runtime apareceu ao acessar o site e se recusou a ir embora.

A correção foi falha, mas eficaz: excluí o diretório do projeto e baixei-o novamente do controle de origem. Mesmo não havendo diferença entre antes e depois, consegui construir o projeto e acessar a página sem reclamações.

Encontrei isso agora em um projeto de Teste de Unidade depois de adicionar MsTest V2 por meio de Nuget. Renomear app.config (removê-lo de forma eficaz) funcionou para mim.

Depois de ler todas as postagens acima, ainda não tenho certeza do porque, desculpe!

Corrigi o problema removendo o Pacote Nuget System.Runtimee reinstalando-o

Em app.config ou web.config adicione

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

Tive um projeto com o mesmo problema, resolvi com a mudança da versão do dotnet core de 2.2 para 2.0, se o problema persistir, tente esta solução

Antes de executar os testes de unidade, apenas remova as tags de tempo de execução do arquivo app.config. O problema será resolvido.

Tive um problema semelhante no VS 2017 15.45 - descobri quando verifiquei que, embora o projeto tenha sido compilado e executado, ele apresentou um system.IO.FileNotFoundException em relação a System.Runtime quando tentei acessar objetos TPL Dataflow.

Quando verifiquei os projetos na solução, um deles (o primeiro) não tinha o pacote System.Runtime usado pelos projetos subjacentes. Depois de instalar a partir do Nuget, tudo funcionou corretamente.

Tentei todas as soluções aqui, mas sem sucesso. Eventualmente, resolvi abrindo o novo arquivo csproj e adicionando manualmente a seguinte seção:

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

Estou usando ASP.Net CORE 2.1 e recebi este erro quando executei selecionando um .csproj de uma lista de cerca de 40 em um grande repo. Quando abri o arquivo csproj individualmente, o erro foi resolvido. Algo em como o programa foi lançado era diferente quando o csproj foi aberto.

Eu resolvo esse problema mudando do .NET 4.7.2 => .NET 4.5.2 e, em seguida, volto para o 472. Portanto, em alguns casos, esse erro ocorre porque o gerenciador de pacotes não conseguiu resolver as dependências

Se estiver funcionando anteriormente, deve haver uma alteração no App.config. Desfazer App.config funcionou para mim.

Eu também passei por esse erro e compartilhei como me livrei dele.

No meu caso, a linha abaixo existia em web.config do projeto webapi, mas não havia referência de pacote no arquivo package.config.

Código em Web.config no Projeto 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>

Código I adicionado no arquivo packages.config no projeto de API da web Antes de fechar o elemento.

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

Outra solução funcionou no meu caso:

Outro atalho claro que pode funcionar no caso de você ter copiado o projeto para outro sistema de computador que pode ter versões de pacote pouco diferentes. Você pode tentar alterar a versão do assembly para a versão fornecida por erro no site / webapi ao executá-lo. Como neste caso, conforme indicado na questão A versão necessária é '4.1.0.0', então simplesmente tente alterar a versão atual em web.config para a versão mostrada com erro conforme abaixo

Erro:

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

Eu tive este erro ocorrendo ao construir uma Função do Azure (com um gatilho de fila, se isso fizer diferença)

O problema neste caso era porque o AzureFunctionsVersionfoi definido como v2 em vez de v3. Para atualizá-lo via VS2019, descarregue o projeto e edite o arquivo csproj. Dentro do PropertyGroupnó, adicione / edite o seguinte:

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