Visual Studio 2017: no se pudo cargar el archivo o ensamblado 'System.Runtime, Version = 4.1.0.0' o una de sus dependencias

Estoy usando Visual Studio 2017 y estoy tratando de crear una biblioteca .Net Standard 1.5 y usarla en un proyecto de prueba .Net 4.6.2 nUnit.

Estoy teniendo el siguiente error...

No se pudo cargar el archivo o ensamblado 'System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' o una de sus dependencias. El sistema no puede encontrar el archivo especificado.

He probado lo siguiente:

1. Haga referencia a la biblioteca Std como referencia del proyecto. Error: me da el error anterior.
2. Cree un paquete NuGet para mi biblioteca Std y haga referencia a eso. Error: el tipo es System.String, esperando System.String. Esto se debe a que System.Runtime terminó siendo referenciado por el proyecto y tiene definiciones para todos los tipos estándar.
3. Consulte NuGet pkg NetStandard.Library. Error: dame el mismo error que # ("El tipo es System.String, esperando System.String"). NOTA: Antes de hacer esto, borré TODOS los paquetes NuGet del proyecto y luego agregué solo los paquetes nUnit y NetStandard.Library (que instalaron otros 45 paquetes).

¿Es esto un error? ¿Existe una solución alternativa? Se agradece cualquier ayuda.

Tuve el mismo problema y ninguna solución sugerida que encontré funcionó. Mi solución para este problema fue: Verifique App.config y packages.config para ver si las versiones coinciden.

Originalmente, mi app.config contenía:

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

Pero el packages.config contenía:

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

Modifiqué la entrada app.config para que coincida con packages.config para la nueva versión:

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

Después del cambio, el problema se resolvió.

Este problema ocurre cuando hace referencia a un proyecto .NET Standard desde un proyecto .NET 4.x: ninguna de las referencias de paquetes nuget del proyecto .NET Standard se incluye como dependencias.

Para solucionar esto, debe asegurarse de que su archivo .NET 4.x csproj apunte a las herramientas de compilación actuales (al menos 14):

<Project ToolsVersion="15.0">...

Lo siguiente ya no debería ser necesario, se corrigió alrededor de VS 15.3:

Hubo un error conocido en VS2017, específicamente en NuGet 4.0.

Para solucionar el error, deberá abrir el archivo .csproj para su proyecto .NET 4.xy agregar este fragmento:

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

NuGet 4.x trae consigo la "referencia del paquete", no más packages.config, pero la antigua canalización 4.x no se actualizó por completo en el momento del lanzamiento de VS2017. El fragmento anterior parece "despertar" el sistema de compilación para incluir correctamente las referencias de paquetes de las dependencias.

Encontré este problema recientemente y probé muchas cosas mencionadas en este hilo y en otros. Añadí referencia paquete para "System.Runtime"mediante el gestor de paquetes Nuget, ha solucionado el redicts de unión en app.config, y asegúrese de que app.configy package.configtener la misma versión para el montaje. Sin embargo, el problema persistió.

Finalmente, quité la <dependentAssembly>etiqueta para el montaje y el problema desapareció. Entonces, intente eliminar lo siguiente en su 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: Después de actualizar .NET Framework a 4.7.2, el problema resurgió. Probé el truco anterior pero no funcionó. Después de perder muchas horas, me di cuenta de que el problema se debía a una System.Linqreferencia antigua en app.config. Por lo tanto, elimine o actualice todas las referencias de Linq también para deshacerse de este problema.

Créame, no estoy bromeando. Elimine todas las dependencias System.Runtime de su app.config y comenzará a funcionar.

Resolví ese error haciendo referencia a NetStandard.Library y al siguiente archivo app.config en 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

Si falta algo diferente a System.Runtime, System.Reflectiono System.Runtime.InteropServicesfalta (por ejemplo System.Linq), simplemente agregue un nuevo dependentAssemblynodo.

Editar 2

En las nuevas versiones de Visual Studio (creo que 2017 15.8) es posible que Studio cree el archivo app.config. Simplemente marque la casilla de verificación Generar automáticamente redirecciones de enlace en Propiedades del proyecto - Aplicación .

Editar 3

Las redirecciones de enlace de generación automática no funcionan bien con las bibliotecas de clases .NET. Agregar las siguientes líneas a los archivos csproj resuelve esto y se generará un archivo .config funcional para Classlibary.

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

Lo arreglé borrando mi app.configcon

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

entradas.

app.config se agregó automáticamente (pero no es necesario) durante la refactorización

Este problema ocurre cuando hace referencia a un proyecto .NET Standard desde un proyecto .NET 4.x: ninguna de las referencias de paquetes nuget del proyecto .NET Standard se incluye como dependencias.

Lo resolví 4.3agregando el paquete System.Runtime y NETStandard.Library y !! importante !! Utilizo la herramienta de refactorización para buscar la versión System.Runtime.dll, 4.1.1.1no lo es 4.3y luego agrego un bindingRedirect en .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>

es demasiado tarde, lo sé, sin embargo, no hay una respuesta satisfactoria. Encontré la respuesta en otro sitio web. Solucioné el problema cuando elimino la dependencia de ensamblado System.Runtime. Eliminé esto.

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

Atentamente

Tuve un problema con esto en un proyecto NUnit 2.6.4 dirigido a dotnet framework 4.6.2. Me encontré con ese System.Runtime FileNotFounderror al intentar usar Humanizer .

Arreglé mi error instalando NetStandard.Library en mi proyecto de prueba unitaria.

Hemos descubierto que AutoGenerateBindingRedirectspodría estar causando este problema.

Observado: el mismo objetivo del proyecto net45y netstandard1.5se construyó con éxito en una máquina y no se pudo construir en la otra. Las máquinas tenían diferentes versiones del framework instaladas (4.6.1 - éxito y 4.7.1 - fracaso). Después de actualizar el marco en la primera máquina a 4.7.1, la compilación también falló.

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 redirectses una característica de .net 4.5.1. Siempre que nuget detecte que el proyecto hace referencia transitiva a diferentes versiones del mismo ensamblado, generará automáticamente el archivo de configuración en el directorio de salida y redirigirá todas las versiones a la versión requerida más alta.

En nuestro caso, se volvieron a unir todas las versiones de System.Runtimeto Version=4.1.0.0. .net 4.7.1se envía con una 4.3.0.0versión de runtime. Por lo tanto, el enlace de redireccionamiento se asignaba a una versión que no estaba disponible en una versión contemporánea del marco.

El problema se solucionó al deshabilitar las redirecciones de enlace automático para el objetivo 4.5 y dejarlo solo para .net core.

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

Este problema tiene muchas causas ... en mi caso, el problema fue que estaba en mi web.config una etiqueta agregando el ensamblado System.Runtime:

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

pero un paquete también agregó el mismo ensamblado como dependencia con otra versión:

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

eliminar la etiqueta "agregar ensamblaje" de mi web.config resolvió el problema.

Parece que el problema se produce cuando hay un conflicto de versiones entre packages.config y app.config. En app.config tiene redireccionamientos de enlace de ensamblaje generados automáticamente por algo llamado "AutoGenerateBindingRedirects". Cuando esté habilitado cada vez que descargue el paquete nuget, además de hacer una nueva entrada en packages.config, agregará esta información de redirección de enlace a app.config, cuál es el propósito de esto se explica aquí: Redireccionamiento de enlace de ensamblado: ¿Cómo y por qué?

Allí puede leer lo que escribió el usuario @Evk:

¿Por qué son necesarios los redireccionamientos vinculantes? Suponga que tiene la aplicación A que hace referencia a la biblioteca B y también a la biblioteca C de la versión 1.1.2.5. La biblioteca B, a su vez, también hace referencia a la biblioteca C, pero de la versión 1.1.1.0. Ahora tenemos un conflicto, porque no puede cargar diferentes versiones del mismo ensamblado en tiempo de ejecución. Para resolver este conflicto, puede usar la redirección de enlace, generalmente a la nueva versión

Entonces, CORRECCIÓN RÁPIDA: elimine todas las entradas en app.config.

En mi caso, con solo hacer que el programa comenzó a funcionar, pero probablemente funcionará solo si no tiene ningún conflicto de versiones del mismo ensamblado en tiempo de ejecución.

Si tiene tal conflicto, debe corregir estos números de versión en app.config para que coincidan con las versiones realmente utilizadas de los ensamblajes, pero el proceso manual es doloroso, por lo que sugiero generarlos automáticamente nuevamente abriendo la Consola del Administrador de paquetes y realizar la reinstalación de paquetes escribiendo Update-Package -reinstall

Terminé en esta situación varias veces con mi sitio web .NET 4.6.1. Creé el problema cada vez que agregué una referencia a un proyecto de .NET Core separado. Al construir, Visual Studio me alertó correctamente de que tales referencias entre marcos no son válidas y eliminé rápidamente la referencia del proyecto. El proyecto se construyó bien después de eso, pero el error System.Runtime apareció al acceder al sitio web y se negó a desaparecer.

La solución cada vez fue poco convincente pero efectiva: eliminé el directorio del proyecto y lo volví a descargar desde el control de código fuente. Aunque no hubo diferencia entre el antes y el después, pude construir el proyecto y acceder a la página sin quejas.

Me encontré con esto hace un momento en un proyecto de prueba unitaria después de agregar MsTest V2 a través de Nuget. Cambiar el nombre de app.config (eliminarlo de manera tan efectiva) funcionó para mí.

Habiendo leído todas las publicaciones anteriores, todavía no estoy seguro de por qué, ¡lo siento!

Solucioné el problema quitando el paquete Nuget System.Runtimey luego reinstalándolo

En app.config o web.config agregue

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

Tuve un proyecto con el mismo problema, lo resolví cambiando la versión de dotnet core de 2.2 a 2.0, si su problema ha permanecido, pruebe esta solución

Antes de ejecutar las pruebas unitarias, simplemente elimine las etiquetas de tiempo de ejecución del archivo app.config. El problema se resolverá.

Tuve un problema similar en VS 2017 15.45: descubrí cuando verifiqué que, aunque el proyecto se compiló y ejecutó, surgió una excepción system.IO.FileNotFoundException con respecto a System.Runtime cuando intenté acceder a los objetos de TPL Dataflow.

Cuando verifiqué los proyectos en la solución, a uno de ellos (el superior) le faltaba el paquete System.Runtime utilizado por los proyectos subyacentes. Una vez que lo instalé desde Nuget, todo funcionó correctamente.

Probé todas las soluciones aquí, pero fue en vano. Finalmente, lo resolví abriendo el nuevo archivo csproj y agregué manualmente la siguiente sección:

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

Estoy usando ASP.Net CORE 2.1 y recibí este error cuando ejecuté seleccionando un .csproj de una lista de aproximadamente 40 en un gran repositorio. Cuando abrí el archivo csproj individualmente, se resolvió el error. Algo con la forma en que se inició el programa fue diferente cuando se abrió el csproj.

Resuelvo este problema cambiando de .NET 4.7.2 => .NET 4.5.2 y luego vuelvo a 472. Entonces, en algunos casos, este error ocurre porque el administrador de paquetes no puede resolver las dependencias

Si está funcionando anteriormente, entonces debería haber un cambio en App.config. Deshacer App.config funcionó para mí.

También pasé por este error y compartí cómo me deshice de él.

En mi caso, la siguiente línea existía en web.config del proyecto webapi pero no había una referencia de paquete en el archivo package.config.

Código en Web.config en 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>

Código que agregué en el archivo packages.config en el proyecto web api antes de cerrar el elemento.

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

Otra solución funcionó en mi caso:

Otro corto seguro que puede funcionar en caso de que haya copiado el proyecto a otro sistema informático que puede tener pequeñas versiones de paquetes diferentes, puede intentar cambiar la versión de ensamblaje a la versión dada por error en el sitio web / webapi cuando lo ejecuta. Como en este caso, como se indica en la pregunta, la versión necesaria es '4.1.0.0', así que simplemente intente cambiar la versión actual en web.config a la versión que se muestra en el error como se muestra a continuación

Error:

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

Tuve este error al crear una función de Azure (con un disparador de cola, en caso de que haga una diferencia)

El problema en este caso fue porque AzureFunctionsVersionse configuró en v2 en lugar de v3. Para actualizarlo a través de VS2019, descargue el proyecto y luego edite el archivo csproj. Dentro del PropertyGroupnodo, agregue / edite lo siguiente:

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