asp.net - No se pudo cargar el archivo o el ensamblaje o una de sus dependencias. Acceso denegado. El problema es aleatorio, pero después de que ocurre una vez, continúa

.net-assembly (18)

Creo que perdí como 1 día en investigarlo y esto con lo que he salido.

Debe agregar el usuario de suplantación de identidad a la carpeta de depuración de su solución, ya que el Framework intentará acceder al archivo DLL desde esta ubicación y colocarlo en la carpeta Asp.Net temporal.

Entonces, básicamente sigue estos 2 pasos

Otorgue permiso a la Carpeta Asp.Net temporal en C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files y asegúrese de que el usuario que está agregando aquí sea el mismo que está utilizando mientras hace una suplantación.
Agregue el usuario Suplantador a la carpeta Depurar de su Solución YourSolutionPath .. / bin / Debug

Esto debería funcionar

He encontrado mucha información sobre este error: ''ERROR: no se pudo cargar el archivo o ensamblado'' * .dll ''o una de sus dependencias. Acceso denegado.'' Pero no he encontrado respuesta específica a mi escenario. Mi sitio se implementa en 6 servidores de producción diferentes, solo en un servidor me enfrento a este problema. El problema es aleatorio, pero después de que ocurre una vez, continúa hasta que el sitio se recompila mediante una pequeña modificación en el archivo web.config (lo sé truco, después de la modificación en web.config recompila la aplicación web) y el sitio en ese servidor comienza trabajando. Ayer, el problema se reproducía después de un mes de trabajo. No podemos permitirnos este problema en la producción.
Detalle del problema:

Error del servidor en la aplicación ''/''. ____________________________________ No se pudo cargar el archivo o ensamblado ''MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null'' o una de sus dependencias. Acceso denegado. Descripción: se produjo una excepción no controlada durante la ejecución de la solicitud web actual. Revise el seguimiento de la pila para obtener más información sobre el error y dónde se originó en el código.
Detalles de la excepción: System.IO.FileLoadException: no se pudo cargar el archivo o ensamblado ''MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null'' o una de sus dependencias. Acceso denegado.
Error de origen: se generó una excepción no controlada durante la ejecución de la solicitud web actual. La información sobre el origen y la ubicación de la excepción se puede identificar utilizando el seguimiento de pila de excepción a continuación.
Rastreo de carga de ensamblaje: la siguiente información puede ser útil para determinar por qué no se pudo cargar el ensamblado ''MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null''.
WRN: el registro de enlace de ensamblaje está APAGADO. Para habilitar el registro de fallas de enlace de ensamblaje, establezca el valor de registro [HKLM / Software / Microsoft / Fusion! EnableLog] (DWORD) en 1. Nota: Hay una cierta penalización de rendimiento asociada con el registro de fallas de enlace de ensamblaje. Para desactivar esta función, elimine el valor de registro [HKLM / Software / Microsoft / Fusion! EnableLog].
Stack Trace:
[FileLoadException: no se pudo cargar el archivo o ensamblado ''MainCore.DbImpl, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null'' o una de sus dependencias. Acceso denegado.] ... DbImpl.Event.TTCEventController.GetEventFields (Int32 eventId) +0 WebSuite.SportChannel.ModelImpl.TTCModelController.AddEventFieldList (XmlElement eventNode, ITTCEventController ctrl, Int32 eventId, PlayerType stupidType) en ... root / SportChannel / ModelImpl / Ttc / TTCModelController.cs: 171 ... ModelImpl.TTCModelController.GetLatestFourTourSchedulesXml () en ... raíz / SportChannel / ModelImpl / Ttc / TTCModelController.cs: 283 ... WebRoot.UserControls.HeadlinesTab.Page_Load (Object remitente , EventArgs e) +491 System.Web.Util.CalliHelper.EventArgFunctionCaller (IntPtr fp, Object o, Object t, EventArgs e) +25 System.Web.Util.CalliEventHandlerDelegateProxy.Callback (Object Sender, EventArgs e) +42 Sistema. EventHandler.Invoke (Object Sender, EventArgs e) +0 System.Web.UI.Control.OnLoad (EventArgs e) +132 System.Web.UI.Control.LoadRecursive () +66 System.Web.UI.Control.LoadRecursive ( ) +191 System.Web.UI.Control.LoadRecursive () +191 System.Web.UI.Page.ProcessRequestMain (Boolean includeStagesBeforeA syncPoint, Boolean includeStagesAfterAsyncPoint) +2428
____________________________________
Información de la versión: Microsoft .NET Framework Version: 2.0.50727.5446; Versión ASP.NET: 2.0.50727.5420

En mi caso, copié un servicio de un servidor a otro sin realizar una implementación adecuada desde Visual Studio. Larga historia.

De todos modos, había configurado todos los permisos NTFS apropiados y todo lo demás, pero aún no podía cargar la DLL principal para el servicio.

Lo arreglé cambiando el nombre del archivo service.pdb correspondiente a otra cosa.

Por ejemplo, aquí está mi carpeta bin: /bin/ service.dll service.dll.config service.pdb Cambié el nombre de service.pdb a zzservice.pdb, y luego el service.dll cargó bien.

En mi caso, estaba usando una suplantación simple y el usuario de suplantación tuvo problemas para acceder a uno de los ensamblajes del proyecto. Mi solución:

Busque el mensaje de la excepción interna para identificar el ensamblaje problemático.
Modifique las propiedades de seguridad del archivo de ensamblaje.
a) Agregue la cuenta de usuario que está utilizando para la suplantación al grupo y a los nombres de usuario.
b) Dar a esa cuenta de usuario acceso completo al archivo de ensamblaje.

En mi caso, se debió a la función de protección de acceso de mi antivirus (McAfee). Obviamente estaba bloqueando el acceso a este archivo, a partir de ese error.

Lo deshabilité y se ejecutó la solución. Es posible que desee comprobar cualquier aplicación de utilidad que pueda tener en ejecución que pueda estar afectando el acceso a algunos archivos.

Estoy configurando el entorno en el nuevo servidor. Mi web.config obtuvo el nodo de identidad como se muestra a continuación. Cuando me enfrenté a "No se pudo cargar el archivo o ensamblado o una de sus dependencias. Acceso denegado. El problema es aleatorio, pero después de que ocurre una vez, continúa"

Se agregó ccs / HJKWeb como lista de usuarios de mi nuevo servidor.

<authentication mode="Windows" /> <identity impersonate="true" password="******" userName="ccs/HJKWeb" />

Ir a IIS -> Grupo de aplicaciones -> Configuración avanzada -> Activar aplicaciones de 32 bits

Me encontré con este problema y resultó que un paquete / ensamblado referenciado estaba siendo encriptado por Windows. Esto sucedió porque mi empresa implementó una política para exigir que se encriptara la carpeta Mis documentos y mis soluciones de Visual Studio pasaron a estar bajo ese directorio.

Podría acceder manualmente a las propiedades de archivo / directorio en Windows Explorer y desactivar el cifrado. Pero en mi caso, esta era una solución temporal, ya que la política de red eventualmente la cambiaría. Terminé moviendo mi solución VS a otra ubicación no encriptada.

Me salió este error desde VS. Resultó que había abierto una solución sin ejecutar Visual Studio como administrador. Cerrar Visual Studio y volver a ejecutarlo como administrador, y luego reconstruirlo resolvió esto para mí.

Espero que ayude a alguien.

Mi solución es la siguiente:

No encontré una carpeta raíz en C:/Windows/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files .

Google me dijo que podría ser un problema de permiso contra el usuario actual, luego descubrí que tengo una Identidad actual: IIS APPPOOL en el servidor que funciona mal y el resto del servidor tiene Current Identity: NT AUTHORITY/NETWORK SERVICE .

Luego cambié la Identidad actual de IIS APPPOOL a NT AUTHORITY/NETWORK SERVICE .

A partir de aquí, descubrí que restablecer la aplicación web reconstruye el caché ASP.NET temporal y resuelve el problema.

No estaba usando suplantación en mi caso. Mi solución fue dar acceso completo a mi directorio de proyectos para el grupo de usuarios "IIS_IUSRS".

Para mi caso, descubrí que había un nodo de identidad en el archivo web.config.

<identity impersonate="true" userName="blah" password="blah">

Cuando eliminé los parámetros userName y password del nodo, comenzó a funcionar.

Otra opción podría ser que deba asegurarse de que el nombre de usuario especificado tenga acceso para trabajar con las carpetas "Archivos temporales ASP.NET" que se encuentran en las distintas carpetas C: / Windows / Microsoft.NET / Framework {version}.

¡Espero que esto ayude a alguien más a salir!

Si aún te enfrentas al problema, prueba esto:

Abra su Administrador de IIS -> Grupos de aplicaciones -> seleccione su grupo de aplicaciones -> Configuración avanzada -> En ''Modelo de proceso'' establezca la configuración ''Cargar perfil de usuario'' como Verdadero

Si está utilizando una suplantación, asegúrese de otorgar permisos, incluidos los permisos de escritura y modificación a la cuenta de usuario relevante en la siguiente carpeta:

C:/Users/[username]/AppData/Local/Temp/Temporary ASP.NET Files

Me faltaba el permiso de modificación, que era el motivo por el que simplemente agregar los permisos predeterminados no funcionaba para mí.

Tuve el mismo problema, solucionado al reconstruir y volver a desplegar TODOS los archivos Dll dependientes

Tuve el mismo problema, solucionado con la configuración del parámetro "Habilitar aplicaciones de 32 bits" en "verdadero" (en la configuración avanzada de mi grupo de aplicaciones).

Verifique la configuración de IIS. Uso IIS 7.5 con compilación de 32 o 64 bits en .NET framework. Si tiene una aplicación que usa el modo de 32 bits, asegúrese de habilitar el grupo de aplicaciones para que pueda usar instrucciones de 32 bits. De lo contrario, nada parece funcionar, sin importar cuánto establezca la seguridad o firme la DLL.

A cualquier persona que haya probado la mayoría de las soluciones y aún tenga problemas.

Mi solución es diferente a las demás, que se encuentra en la parte inferior de esta publicación, pero antes de intentarlo, asegúrese de haber agotado las siguientes listas. Para estar seguro, los he probado todos pero fue en vano.

Vuelva a compilar y volver a implementar desde el principio, no actualice la aplicación existente. Pues contesta
Otorgue acceso completo a IIS_IUSRS al directorio "C: / Windows / Microsoft.NET / Framework / v4.0.30319 / Archivos temporales ASP.NET"
Tenga en cuenta la versión de marco que está utilizando. Si su aplicación utiliza suplantación, use esa identidad en lugar de IIS_IUSRS
Elimine todos los contenidos del directorio "C: / Windows / Microsoft.NET / Framework / v4.0.30319 / Archivos temporales ASP.NET" .
Tenga en cuenta la versión de marco que está utilizando
Cambia la identidad de la AppPool que está usando tu aplicación, desde ApplicatonPoolIdentity a NetworkService.
IIS> Grupos de aplicaciones> Seleccionar grupo de aplicaciones actual> Configuración avanzada> Identidad.
SO Answer (restaurar a los valores predeterminados si no funciona)
Verifique la versión de IIS y la compatibilidad de la versión .NET de AppPool con su aplicación. Altamente aplicable a las implementaciones por primera vez. Pues contesta
Verifique la configuración de suplantación si corresponde. Pues contesta

Mi solución:

Descubrí que ciertos softwares anti-virus están bloqueando activamente las compilaciones de archivos DLL dentro del directorio "Archivos temporales ASP.NET" , el mío era McAfee, la gente de TI no me notificó sobre la instalación.

Según las recomendaciones de los expertos de McAfee y Microsoft, debe excluir el directorio "Archivos ASP.NET temporales" en el análisis en tiempo real.

Fuentes:

No desactive el Anti-Virus porque solo está haciendo su trabajo. No copie manualmente los archivos DLL que faltan en el directorio / Archivos temporales ASP.NET {nombre del proyecto} porque es una grabación en ductos.

Go to run : ctrl + R Type : %temp%

eliminar todos los archivos y carpetas

Rebuild Project. done!