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

visual-studio-2017 .net-standard-1.5 (20)

Estoy usando Visual Studio 2017 e intento 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:

Biblioteca estándar de referencia como referencia del proyecto. Error: me da el error anterior.
Crear un paquete NuGet para mi biblioteca Std y hacer 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.
Referencia 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 instaló otros 45 paquetes).

¿Es esto un error? ¿Hay una solución alternativa? Cualquier ayuda es apreciada.

Confía en mí, no estoy bromeando. Elimine todas las dependencias System.Runtime de su app.config y comenzará a funcionar.

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>

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í agregando System.Runtime 4.3 y NETStandard.Library package y ¡¡importante !! Utilizo la herramienta refactor para buscar la versión System.Runtime.dll, es 4.1.1.1 no 4.3 y luego agrego un enlaceRedirect 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>

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 solucionó alrededor de VS 15.3:

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

Para evitar el error, deberá abrir el archivo .csproj para su proyecto .NET 4.x y agregar este fragmento:

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

NuGet 4.x trae consigo la "referencia de paquete", no más paquetes.config, pero la antigua tubería 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 referencias de paquetes de dependencias.

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

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

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

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

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

Estoy usando ASP.Net CORE 2.1 y obtuve 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 en cómo se lanzó el programa fue diferente cuando se abrió csproj.

Hemos descubierto que AutoGenerateBindingRedirects podría estar causando este problema.

Observado: el mismo proyecto dirigido a net45 y netstandard1.5 se construyó con éxito en una máquina y no se pudo construir en la otra. Las máquinas tenían instaladas diferentes versiones del framework (4.6.1 - éxito y 4.7.1 - falla). 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 redirects es una característica de .net 4.5.1 . Siempre que nuget detecte que el proyecto hace referencia de forma transitiva a diferentes versiones del mismo ensamblaje, generará automáticamente el archivo de configuración en el directorio de salida redirigiendo todas las versiones a la versión más alta requerida.

En nuestro caso, estaba volviendo a vincular todas las versiones de System.Runtime a Version=4.1.0.0 . .net 4.7.1 viene con una versión 4.3.0.0 de tiempo de ejecución. Por lo tanto, el enlace de redireccionamiento se asignaba a una versión que no estaba disponible en una versión contemporánea de framework.

El problema se solucionó deshabilitando los redireccionamientos de enlace automático para el destino 4.5 y dejándolo solo para .net core.

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

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

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

Lo arreglé eliminando mi app.config con

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

entradas.

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

Me encontré con este problema recientemente y probé muchas cosas mencionadas en este hilo y en otros. Agregué la referencia del paquete para "System.Runtime" por el administrador de paquetes nuget, arreglé las prohibiciones de enlace en app.config y me aseguré de que app.config y package.config tengan la misma versión para el ensamblado. Sin embargo, el problema persistió.

Finalmente, eliminé la etiqueta <dependentAssembly> para el ensamblaje y el problema desapareció. Por lo tanto, 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ó. Intenté el truco anterior pero no funcionó. Después de perder muchas horas, me di cuenta de que el problema está ocurriendo debido a una antigua referencia de System.Linq en app.config. Por lo tanto, elimine o actualice todas las referencias de Linq también para deshacerse de este problema.

Me encontré con esto justo ahora en un proyecto de Prueba de Unidad después de agregar MsTest V2 a través de Nuget. Cambiar el nombre de app.config (eliminarlo de manera tan efectiva) fue el truco para mí.

Después de leer todas las publicaciones anteriores, todavía no estoy seguro de por qué, ¡lo siento!

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 funciona anteriormente, entonces debería haber un cambio en App.config. Deshacer App.config funcionó para mí.

Solucioné el problema eliminando Nuget Package System.Runtime y luego reinstalándolo

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 separado de .NET Core. Al compilar, Visual Studio me alertó correctamente de que dichas referencias de marco cruzado 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 origen. Aunque no hubo diferencias entre antes y después, pude construir el proyecto y acceder a la página sin quejas.

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:

Pero los paquetes.config contenían:

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

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

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

NetStandard.Library mi error instalando NetStandard.Library en mi proyecto de prueba de unidad.

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

Cuando revisé 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.

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

NetStandard.Library 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 más que System.Runtime , System.Reflection o System.Runtime.InteropServices (por ejemplo, System.Linq ), simplemente agregue un nuevo nodo dependentAssembly .

Editar 2

En las nuevas versiones de Visual Studio (2017 15.8, creo) es posible que Studio cree el archivo app.config. Simplemente marque la casilla de verificación Auto-generar enlaces redireccionamientos en Proyecto-Propiedades - Aplicación .

Editar 3

La generación automática de redireccionamientos de enlace no funciona bien con las bibliotecas de clases .NET. Agregar las siguientes líneas a los archivos csproj resuelve esto y se generará un archivo .config que funcione para Classlibary.

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