No se pudo cargar el archivo o el ensamblaje ... El parámetro es incorrecto

Recientemente me encontré con la siguiente excepción en la solución C #:

Error 2 No se pudo cargar el archivo o ensamblado 'Newtonsoft.Json, Versión = 3.5.0.0, Cultura = neutral, PublicKeyToken = b9a188c8922137c6' o una de sus dependencias. El parámetro es incorrecto. (Excepción de HRESULT: 0x80070057 (E_INVALIDARG))

Esto no depende ni de mi código ni del nombre del ensamblado (como Newtonsoft.Jsonen este caso).

Cuando elimino este dll de la solución, el compilador informa sobre otro en la misma excepción. Así que supongo que algo debería estar apagado / encendido en mi PC :)

Parece un ensamblaje dañado al que se hace referencia.

Limpia los dos:

1. la carpeta \ bin de su proyecto

2. la carpeta temporal (debe estar C:\Users\your_username\AppData\Local\Temp\Temporary ASP.NET Filesen Windows 7)

y ver si el error persiste

Dependiendo de si está ejecutando X64, es posible que deba limpiar un par de puntos más. Simplemente limpiar mi directorio de usuarios no fue suficiente.

1. % TEMP% \ Archivos temporales ASP.NET
2. C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Archivos temporales ASP.NET
3. C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales ASP.NET
4. C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Archivos temporales ASP.NET
5. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Archivos temporales ASP.NET

Esta lista crecerá como si tuviera otras versiones del framework instaladas.

Tuve que despejar

C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files

Solo entonces se resolvió el problema.

Para saber qué borrar con seguridad, agregue la siguiente clave de registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog (DWord set to 1).

Entonces verá la salida como a continuación. Esto le indica dónde asp.net está intentando cargar sus archivos DLL. Borrar este directorio

LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\app\AtlasAdvisor\web\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet.DLL.**
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet/Avanade.ViddlerNet.DLL**.

Borre los archivos de marco temporales para su proyecto en: -

C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Archivos temporales ASP.NET \

También puede borrar el directorio de paquetes y permitir que NuGet vuelva a descargar los paquetes que faltan

me resolvió el problema

Eliminar todos los archivos de estas carpetas.

C: /Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files C: /Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files

Conseguir un nuevo conjunto de binarios del control de Source ayudó.

Gracias

Simplemente borre esta carpeta: (solo Windows x64)

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales ASP.NET

Gracias Alex, tu segundo punto me ayudó a arreglar esto.

Parece que a menos que ejecute Visual Studio como administrador en Windows 7, almacena sus archivos temporales localmente en lugar de C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Archivos temporales ASP.NET.

Consulte la siguiente publicación de blog: http://www.dotnetscraps.com/dotnetscraps/post/Location-of-Temporary-ASPNET-files-in-Vista-or-Windows-7.aspx

Tuve el mismo problema aquí: las soluciones anteriores no funcionaron. El problema fue con ActionMailer. Ejecuté los siguientes comandos de desinstalación e instalación de nuget

uninstall-package ActionMailer
install-package ActionMailer

Resolvió mis problemas, espero que ayude a alguien más.

Esto puede suceder al hacer referencia a los archivos DLL de contenedor COM. Dentro de su proyecto de Visual Studio, en Referencias, seleccione los dlls de contenedor COM a los que se hace referencia y asegúrese de que tengan los siguientes valores de propiedad: "Tipos de interoperabilidad de incrustación": Falso y "Versión específica": Falso.

Solo elimino los datos temporales de mi aplicación de esta ruta

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files

Problema resuelto

Veo que muchos técnicos han publicado sobre la eliminación de directorios temporales de ASP .Net en tiempo de ejecución relacionados con todos y cada uno de los marcos .Net alojados en su máquina como en esta respuesta. Pero creo que deberíamos conocer la logística clara de por qué necesitamos borrar ciegamente todos los directorios de trabajo temporales de todos los marcos .Net. Según yo, no debería ser el caso.

Mi consejo sería que intentes un enfoque de eliminación de directorios con punta de alfiler para resolver este problema. ¿Cómo sabrías qué directorio borrar?

1. Vaya a IIS y haga clic derecho en el nodo de su sitio web en el panel de navegación izquierdo para abrir el menú contextual. En el menú contextual, seleccione Manage Application-> Advanced Settings...para abrir la Advanced Settingsventana.
2. Verifique el grupo de aplicaciones al que está asignado su sitio web. En mi caso es DefaultAppPoolcomo se muestra a continuación:

3. Ahora vaya al Application Poolsnodo en la barra de navegación izquierda en el IIS. Ahora compruebe qué versión de .Net CLR está ejecutando su grupo de aplicaciones. En mi caso es v4.0 como se muestra a continuación:

Dado que la versión CLR que aloja mi grupo de aplicaciones es v4.0, eliminé con precisión solo los archivos temporales en la carpeta perteneciente a ASP .NET v4.0 solo de la siguiente manera:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

Y eso es. Mi problema se resolvió.

Lección aprendida : Esto es indicativo del hecho de que todos los archivos temporales que utiliza su sitio web no están dispersos en varios directorios, sino que al mismo tiempo son remitidos por su grupo de aplicaciones. Por lo tanto, solo debe borrar esa carpeta específica.

Borrar C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Los archivos temporales de ASP.NET funcionaron para mí. Pensando en automatizar el proceso de eliminación para evitar el problema en el futuro.

Si está utilizando las Herramientas de datos de SQL Server 2012, que utiliza el shell VS2010 al 1 de mayo de 2013, verifique la configuración de Configuration Manager. Un cambio de nombre de servidor de Workflow a xCPWorkflow fue suficiente para producir exactamente el mismo mensaje. El parámetro es incorrecto (Excepción de HRESULT: 0x80070057 (E_INVALIDARG)) .

Puede limpiar, construir o reconstruir su aplicación o simplemente eliminar archivos temporales de ASP.NET en C: \ Users \ YOUR USERNAME \ AppData \ Local \ Temp

Esto funciona como magia. En mi caso, tuve un problema de unión de ensamblaje que decía No se pudo cargar el archivo bla bla bla

También puede ver la solución 2 como http://www.codeproject.com/Articles/663453/Understanding-Clean-Build-and-Rebuild-in-Visual-St

Tuve este problema al hacer el controlador en MVC. Cambié la versión .NET Framework. El problema fue resuelto

El problema se relaciona con la versión en tiempo de ejecución .Net de una biblioteca de clases referenciada (referencias expandidas, seleccione la biblioteca y verifique la "Versión en tiempo de ejecución". Tuve un problema con Antlr3.Runtime, después de actualizar mi proyecto de Visual Studio a v4.5. I usé NuGet para desinstalar Microsoft ASP.NET Web Optimization Framework (debido a una cadena de dependencias que me impidió desinstalar Antlr3 directamente)

Luego usé NuGet para reinstalar el Microsoft ASP.NET Web Optimization Framework. Esto reinstaló las versiones correctas de tiempo de ejecución.

En mi caso, quería compilar una DLL visible COM. El problema era que aquí se encontraba una versión anterior de esta DLL:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

Por lo tanto, Visual Studio cargó esta versión en lugar de la recién compilada, ya que intentó registrarla.

Borre todos los archivos de la carpeta temporal (C: \ Users \ nombre_usuario \ AppData \ Local \ Temp \ Archivos temporales ASP.NET \ carpeta de proyecto)

A veces, usted también necesita limpiar esta carpeta: C: \ Windows \ Temp \ Temporary ASP.NET

Me enfrenté al mismo error porque la aplicación no encontró marcos dependientes en la C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\carpeta. Acabo de reparar mi Visual Studio que agregó el marco requerido en la ubicación anterior y funciona bien.

En mi caso, cambiar el número de puerto IISExpress en las propiedades de mi proyecto resolvió el problema.

Si alguien más está usando el conjunto de herramientas WiX, descubrí que mi proyecto de instalación tenía una referencia a un proyecto antiguo que se había eliminado recientemente de la solución. Me tomó un tiempo darme cuenta, ya que hay varios proyectos en la solución que estaba intentando construir y el mensaje no indicaba qué proyecto no se podía construir (y limpiar, que también fallaba).

Tenía usuarios de Siemens Teamcenter 10 Client para Microsoft Office que obtenían el mismo error sobre una DLL diferente. Ninguna de las otras respuestas funcionó. La solución fue eliminar las carpetas en

C:\Users\%username%\AppData\Local\assembly\

Tuve un problema similar al abrir el administrador de paquetes Nuget, eliminé todos los archivos temporales y construí el proyecto, funcionó bien.