Tengo un proyecto VS2017 que se compila en una DLL que luego llama un EXE escrito por otra persona. Ambos proyectos apuntan a .Net Framework 4.6.2. Reescribí uno de mis métodos DLL para devolver una tupla y también importé el paquete NuGet asociado. Cuando compilo el proyecto, incluye System.ValueTuple.dll en el directorio de salida que luego se implementa en otras máquinas donde se carga mi DLL y el EXE lo llama. Pero cuando el EXE intenta llamar al método que devuelve una tupla, falla:
Error inesperado No se pudo cargar el archivo o ensamblado 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' o una de sus dependencias. El sistema no puede encontrar el archivo especificado.
No entiendo por qué no encuentra el archivo, ya que está en la misma carpeta que mi DLL. Aparentemente, MS no incluyó este ensamblaje en .Net Framework 4.6.2.
Tenga en cuenta que mi archivo DLL está registrado en Windows mediante un archivo machine.config. Supongo que si también agrego System.ValueTuple.dll a este archivo, funcionará (aún no lo he probado y no estoy seguro de que este sea el mejor enfoque, especialmente a largo plazo). ¿Hay alguna manera mejor, además de esperar a 4.6? .3 y esperando que incluya este montaje?
Resolví este problema registrando System.ValueTuple en el archivo machine.config de mi computadora (junto con mi propia DLL que ya estaba registrada allí). Sin embargo, no me gusta especialmente este enfoque, ya que depende de la versión de DLL, que está sujeta a cambios en cualquier momento. Con suerte, MS simplemente agregará este ensamblaje a la próxima versión de .Net Framework.
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" /> <bindingRedirect oldVersion="0.0.0.0-99.99.99.99" newVersion="4.0.1.0" /> <codeBase version="4.0.1.0" href="e:\exec\System.ValueTuple.dll" /> </dependentAssembly> ... </assemblyBinding> </runtime>Me enfrenté a la misma excepción cuando hubo una discrepancia en la versión del paquete nuget. (En la DLL se usó 4.3.1 mientras que en el programa principal 4.3.0.) Resolví el problema actualizando los paquetes a la misma versión... Verificar y unificar las versiones de los paquetes también podría ayudarlo.
FWIW, tuve este problema en mi proyecto de prueba usando Moq. Alguien había configurado el proyecto en .NET 4.7, pero yo estaba en 4.6.2. No queriendo pasar a 4.7 todavía, la solución fue degradar la versión a Moq 4.7.145. System.ValueTuple v 4.3.1 funcionó junto con él.
Acabo de tener este problema yo mismo. No en Localhost durante el desarrollo, sino solo en el servidor de producción. Al final, resultó ser una especie de conflicto entre .Net Framework 4.6.1 y yo, que tenía System.ValueTuple instalado desde Nuget en la versión 4.5.0.
La solución resultó ser degradar el paquete System.ValueTuple Nuget a 4.3.0 . Luego funcionó, como si nada hubiera sido un problema.
Sospecho que esto solo sucedió en el servidor de producción, debido a que se instaló una versión diferente de .NET Framework.
ok, esto se siente completamente mal, pero corté
<dependentAssembly> <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" /> </dependentAssembly>Esta fuera de mi web.config para la aplicación principal.
Realmente solo estaba viendo lo que sucedió para ver si había una dependencia subyacente o algo así, sin esperar que se ejecutara. Simplemente siguió funcionando, todas las nuevas funciones que he agregado en los últimos días todavía funcionan.
Tuve este mismo problema con una dependencia de AutoMapper 8.0.0.0 en la versión 4.5 después de actualizar de .NET 4.5.1 a 4.6.1. La reinstalación del paquete nuget de automapper funcionó para mí.
Mi problema era que estaba desarrollando contra 4.6.1, pero lanzando en 4.7.2. Afortunadamente, no me importa para qué marco .Net se creó este proyecto, así que instalé 4.7.2 en mi instancia de desarrollador y luego actualicé todos los paquetes de Nuget.
Lo resolvió instalando .NET Framework 4.7.2 Runtime en la máquina en la que ocurrió el error. Sencillo y sin necesidad de agregar bindingRedirect o degradar los paquetes de NuGet.
https://dotnet.microsoft.com/download/dotnet-framework/net472
Tuve el mismo problema, resuelvo el problema cambiando el marco de destino del proyecto a .Net Framwork 4.7.1.
System.ValueTuple ahora es compatible con .NET Framework 4.7
SI no puede actualizar .Net Framework a la última versión, cambie el paquete: Microsoft.Net.Compilers a la versión 2.10. Esto resolvió el problema en mi caso.
Tenía una biblioteca que usaba una versión más nueva del paquete System.ValueTuple NuGet. Luego usé otra biblioteca que me hizo usar la versión anterior instalada en el proyecto principal por primera vez. Eso hizo que esta excepción se revelara. Actualizar ambos (o hacerlos converger de alguna manera; degradar ambos también está bien) solucionó el problema.
En mi solución encontré 2 creadores de problemas diferentes. Ya sea en el archivo App.config o Web.config:
Discrepancia de versión : la versión instalada a través de NuGet no coincidía con la versión en el archivo de configuración. Solución: cambie la versión manualmente en el archivo .config.
Entradas duplicadas : Encontré entradas duplicadas para ValueTuple. En mi caso uno para 4.0.3.0 y otro para 4.5.0. Eliminar la entrada anterior resolvió el problema.
En otro caso, logré solucionar el problema eliminando las referencias innecesarias y deshaciéndome del paquete ValueTuple NuGet por completo.
Resolví este problema instalando System.ValueTuple desde nuget. No se instaló anteriormente, pero supongo que RestSharp u otra biblioteca lo está usando.
Así que esto lo arregló.
En mi caso, creo que algo eliminó este dll de las carpetas del proyecto y del marco, tal vez durante la instalación de algo que voló; entonces mi proyecto durante la depuración no pudo encontrar ese dll y arrojar ese error. lo instalé
Paquete de instalación System.ValueTuple -Versión 4.5.0
Paquete y que todo funcionó de nuevo. Antes de realizar más soluciones complicadas como se describe anteriormente, es posible que la instalación del paquete ValueTuple funcione para usted.
Si tiene AutoMapper versión 8.0 o inferior a la que se hace referencia en cualquiera de sus proyectos, es posible que sea el origen del problema. Consulte este problema de github para obtener más información.
Si entiendo correctamente, el problema es que las versiones de .NET Framework por debajo de la versión 4.7 no tenían System.ValueTuple enviado con ellas de forma predeterminada, por lo que AutoMapper estaba usando una referencia de paquete NuGet para el ensamblaje, ya que tiene objetivos de compilación para las versiones de Framework por debajo de 4.7. Esto causó algunas cosas funky de Microsoft .
La solución más fácil es actualizar sus referencias de AutoMapper a la version 8.1.0 o más reciente, donde eliminaron todos los usos del ensamblado de su base de código y eliminaron la dependencia.
Agregando a la respuesta de Robin por solo cambiar Web.config. Pude salirme con la mía comentando solo la etiqueta de redireccionamiento vinculante.
<dependentAssembly> <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /> <!--<bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />--> </dependentAssembly>Esto eliminó el error para mí.
Experimenté el mismo error "No se pudo cargar el archivo o ensamblar System.ValueTuple.dll..." en mi Windows Server 2016. Sin embargo, el sitio funcionó bien en mi máquina de desarrollo.
Mi solución fue simple, agarré este dll de mi máquina de desarrollo y lo dejé en la carpeta "bin" del sitio en el servidor. Funcionó.
Lo resolvió instalando VS 2019.
Espero que esto no sea nigromancia de hilos, porque sigue siendo lo más buscado en Google. Lamentablemente, ninguno de los otros comentarios funcionó para mí.
Resolvimos este problema recientemente después de más de un año con este problema. El problema era un paquete llamado ' GitVersion '. Entonces, para cualquiera que todavía esté luchando con esto y mirando los foros, sé que algunos lo están; Le aconsejaría que revise sus paquetes y vea cuáles son sus dependencias.
Se corrigió esto cambiando el indicador Copiar local en mi referencia a System.ValueTuple de copiar siempre a ninguno. (Estaba en un ensamblaje que contenía pruebas).