framework - mvc asp.net c#
No se pudo cargar el archivo o ensamblado ''Antlr3.Runtime(1)'' o una de sus dependencias (21)
Recibo este error al intentar ejecutar mi proyecto MVC4
, funcionaba bien hasta la última vez en mis otras máquinas, pero cuando trato de ejecutarlo desde otra máquina me está dando este error:
No se pudo cargar el archivo o ensamblado ''Antlr3.Runtime (1)'' o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje. (Excepción de HRESULT: 0x80131040)
Después de leer sobre esto, traté de do :
Install-Package Antlr3.Runtime -Pre
pero no ayudó, ¿alguna idea?
¡Actualicé todos los paquetes en el Administrador de paquetes Nudget y funcionó! En mi caso estoy alojando mi sitio web en GoDaddy
Acabo de enfrentar este problema e intenté las soluciones mencionadas anteriormente, pero nada funcionó por el momento. Tuve que eliminar su archivo DLL de bin floder y volver a crear, eliminar todos los archivos replicados de la carpeta de paquetes y restaurar paquetes usando la consola del administrador de paquetes.
Después de intentar eliminar el archivo .netframework temp sin éxito, cambié
<system.web>
<authentication mode="None" />
<compilation debug="true" targetFramework="4.6.1" />
<httpRuntime />
<pages controlRenderingCompatibilityVersion="4.0" />
</system.web>
Con solo targetFramework = "4.6" en lugar de 4.6.1, el sitio web muestra sin errores. Luego volví a cambiar a targetFramework = "4.6.1" y reinicié el servidor. Todo permanece bien.
El de la manera más simple es update antlr y webgrease
- Gestor de consola Goto Package
- entonces intente aplicar estos códigos uno por uno
- PM> Update-Package Antlr
- PM> Actualizar-Paquete WebGrease
Finalmente el error resuelto
En caso de que esto ayude a alguien.
Tuve este problema con una aplicación MVC 5. Al eliminar Antlr3.Runtime.dll del directorio bin y volver a compilar , se solucionó el problema.
En un proyecto, tenía referencia a WebGrease, pero no había un elemento correspondiente en packages.config. Elimino la referencia del proyecto porque ya no la necesito. Ahora funciona.
Hubo un problema con impersonate = "true" en web.config, ¡eliminé la línea que funcionaba!
De nuevo coloqué la línea y le di permiso de administrador al usuario de la cuenta con suplantación, toda mi aplicación funcionó :)
Intente desbloquear el Antlr3.Runtime.dll si agrega la referencia manualmente:
Intente eliminar los archivos temporales para ASP.Net haciendo uno de estos:
- Ingrese% TEMP% en el Explorador de archivos y elimine todos los archivos temporales.
- Vaya a la carpeta "C: / Windows / Microsoft.NET / Framework / v4.0.30319 / Archivos temporales ASP.NET" y elimine todos los archivos.
La solución para mí era ir a Herramientas> Administrador de paquetes NuGet> Administrar paquetes para la solución
A continuación, haga clic en Antlr3 y asegúrese de que esté instalado en:
- El proyecto de inicio
- Cualquier biblioteca usando la reflexión
- Cualquier biblioteca que llame a las bibliotecas que usan la reflexión
En mi caso, eso fue 4 proyectos de profundidad que lo necesitaba. Una vez hecho esto, este problema finalmente se resolvió.
Me encontré con el mismo problema al experimentar con la plataforma de registro de Nlog gratuita.
Esto me ayudó:
Ingrese% TEMP% en el Explorador de archivos y elimine todos los archivos temporales.
Después de eso, no recibí el error al iniciar mi proyecto MVC5 en Visual Studio.
Mi problema fue causado por un cambio en las unidades mapeadas en nuestra Política de grupo. Mi solución tiene la configuración de tempDirectory establecida en Web.config para usar una configuración de unidad de RAM como mi unidad Z :. Aparentemente, comenzaron a usar el Z: drive y los archivos DLL se copiaban a tempDirectory de forma normal, pero luego creo que estaban siendo eliminados por un proceso en el servidor remoto (probablemente el análisis de virus). Solo pude resolver esto usando Process Monitor y filtrando Antlr y viendo que estaba buscando en una ubicación de red para las DLL.
Mi problema fue que la última versión de WebGrease instala la versión 3.4.1.9004 de Antlr. Una vez que instalé WebGrease y luego actualicé Antlr a la versión 3.5.0.2, el error desapareció.
No olvide borrar también los archivos temporales de ASP.NET en Framework64
. Eso hizo el truco para mí.
-
C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files
-
C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files
Para mí, eliminar este nodo en el archivo web.config eliminó el mensaje de error:
<identity impersonate="true" userName="" password="">
Pero lo que realmente funcionó para mí fue otorgar acceso completo (al nombre de usuario especificado en suplantación) a la carpeta Archivos temporales ASP.NET encontrados en C: / Windows / Microsoft.NET / Framework {versión} (o Framework64).
La identidad también se puede almacenar en la Configuración del grupo de aplicaciones del sitio web, en IIS.
Asegúrese de que su paquete nuget esté instalado correctamente, con la versión correcta. Si no funciona nada más, intente volver a agregar la referencia desde una carpeta local y configurarlo en Copiar local.
Para mí, esto fue causado por una falta de coincidencia entre las versiones de depuración y runtime de Antlr.
Finalmente lo resolvió instalando un paquete Antlr diferente: Install-Package Antlr
Para mí, la solución fue ejecutar Visual Studio como administrador. Aparentemente fue un problema de permisos.
Probé todas las respuestas en esta publicación, pero ninguna de ellas funcionó para mí.
Así que eliminé todos los directorios / bin dentro de todos los proyectos de mi solución, limpié y reconstruí la solución y ¡finalmente funcionó!
Toda mi mañana desperdicia trabajando para resolver el problema ...
Si alguna solución resuelve su problema, verifique el archivo web.config, la versión del ensamblado
<dependentAssembly>
<assemblyIdentity name="Antlr3.Runtime" publicKeyToken="eb42632606e9261f" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.5.0.2" newVersion="3.5.0.2" />
</dependentAssembly>
Si está usando suplantación La respuesta es otorgar permiso para que el usuario suplante el acceso a las siguientes carpetas:
C:/Windows/Microsoft.NET/Framework[v4.0.30319 or the version that you''re using]/Temporary ASP.NET Files
Su directorio de sitio.
también es posible que necesite crear una carpeta de la siguiente manera:
C:/Windows/Microsoft.NET/Framework/[v4.0.30319 or the version that you''re using]/Temporary ASP.NET Files/[Application-Name-Goes-Here]
Pero prueba el anterior primero, funcionó para mí.
Esos dos cambios para otorgar el permiso de usuario suplantado para poder guardar los datos temporales y extraer los archivos dll y cualquier archivo necesario de los directorios
lo que funcionó para mí fue eliminar la identidad = true de mi webconfig (bajo las propiedades de system.web) y construir la solución nuevamente y publicarla nuevamente (si es necesario) y funcionó como un hechizo.