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.

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 una respuesta específica para mi escenario. Mi sitio está implementado en 6 servidores de producción diferentes, solo en un servidor estoy enfrentando este problema. El problema es aleatorio, pero después de que sucede una vez, continúa hasta que el sitio se vuelve a compilar mediante una pequeña modificación en el archivo web.config (sé truco, después de la modificación en web.config, vuelve a compilar la aplicación web) y el sitio en ese servidor se inicia trabajando. Ayer, el tema se reproducía después de un mes de trabajo. No podemos permitirnos este problema en 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 la pila de excepciones a continuación.

Seguimiento de carga de ensamblado: 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 ensamblajes está desactivado. Para habilitar el registro de fallas de enlace de ensamblado, establezca el valor de registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) en 1. Nota: Existe una penalización de rendimiento asociada con el registro de fallas de enlace de ensamblado. Para desactivar esta función, elimine el valor de registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

Seguimiento de pila:

[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 stupid \ Int32 eventId, PlayerType32 eventId ... \ ModelImpl \ Ttc \ TTCModelController.cs: 171 ... ModelImpl.TTCModelController.GetLatestFourTourSchedulesXml () en ... root \ SportChannel \ ModelImpl \ Ttc \ TTCModelController.cs: 283 ... WebRoot.UserControls.HeadlinesTab. , EventArgs e) +491 System.Web.Util.CalliHelper.EventArgFunctionCaller (IntPtr fp, Object o, Object t, EventArgs e) +25 System.Web.Util.
____________________________________

Información de versión: Microsoft .NET Framework Versión: 2.0.50727.5446; Versión ASP.NET: 2.0.50727.5420

Para mi escenario, encontré que había un nodo de identidad en el archivo web.config.

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

Cuando eliminé los parámetros de nombre de usuario y contraseña del nodo, comenzó a funcionar.

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

¡Espero que esto ayude a alguien más!

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

Mi solución es la siguiente:

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

Google me dijo que podría ser un problema de permisos en contra de usuario actual, entonces me di cuenta de que tienen una identidad de corriente: IIS APPPOOLen el servidor de errores, donde el resto del servidor tiene identidad actual: NT AUTHORITY\NETWORK SERVICE.

Luego cambié la Identidad actual de IIS APPPOOLa NT AUTHORITY\NETWORK SERVICE.

Desde aquí, descubrí que al restablecer la aplicación web se reconstruye la caché temporal de ASP.NET, resolviendo el problema.

A cualquier otra 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 probarla asegúrate de haber agotado las siguientes listas. Sin duda, los he probado todos, pero fue en vano.

1. Vuelva a compilar y vuelva a implementar desde cero, no actualice la aplicación existente. Pues contesta

2. Otorgue a IIS_IUSRS acceso completo al directorio "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales ASP.NET"

   Tenga en cuenta la versión del marco que está utilizando. Si su aplicación usa la suplantación de identidad, use esa identidad en lugar de IIS_IUSRS

3. Elimine todo el contenido del directorio "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales ASP.NET" .

   Tenga en cuenta la versión del marco que está utilizando

4. Cambie la identidad de AppPool que usa su aplicación, de ApplicatonPoolIdentity a NetworkService.

   IIS> Grupos de aplicaciones> Seleccionar grupo de aplicaciones actual> Configuración avanzada> Identidad.

   SO respuesta (restaure a los valores predeterminados si no funciona)

5. Verifique la compatibilidad de la versión de IIS y AppPool .NET con su aplicación. Muy aplicable a implementaciones por primera vez. Pues contesta

6. Verifique la configuración de suplantación, si corresponde. Pues contesta

Mi solución:

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

Según los consejos de los expertos de McAfee y Microsoft, debe excluir el directorio "Archivos temporales de ASP.NET" en el escaneo en tiempo real.

Fuentes:

• Foro de soporte de McAfee
• Soporte de Microsoft
• Foro de Asp.Net

No desactive el antivirus 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 eso es cinta adhesiva.

Si está utilizando la suplantación de identidad, asegúrese de otorgar permisos, incluido el permiso 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, por lo que agregar los permisos predeterminados no me funcionaba.

Si aún enfrenta el problema, intente esto:

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

Creo que desperdicié como 1 día investigando y esto es lo que he encontrado.

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

Así que básicamente sigue estos 2 pasos

1. Otorgue permiso a la carpeta Asp.Net temporal debajo C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Filesy asegúrese de que el usuario que está agregando aquí sea el mismo que está usando mientras se hace pasar por persona.

2. Agregue el usuario de suplantación a la carpeta Debug de su solución YourSolutionPath .. \ bin \ Debug

Esto debería funcionar

Tuve el mismo problema, solucionado reconstruyendo y volviendo a implementar TODOS los archivos Dll dependientes

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, por lo que el error.

Lo desactivé y la solución se ejecutó. Es posible que desee verificar cualquier aplicación de utilidad que pueda estar ejecutando y que podría estar afectando el acceso a algunos archivos.

Vaya a IIS -> Grupo de aplicaciones -> Configuración avanzada -> Habilitar aplicaciones de 32 bits

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

Estoy configurando el entorno en un nuevo servidor. Mi web.config obtuvo un nodo de identidad como el siguiente. Cuando me enfrenté con "No se pudo cargar el archivo o ensamblado o una de sus dependencias. Se deniega el acceso. El problema es aleatorio, pero después de que ocurre una vez, continúa"

Agregué ccs \ HJKWeb como lista de usuarios de mi nuevo servidor.

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

Para mí, el siguiente truco funcionó; Vaya a IIS -> Grupos de aplicaciones -> Configuración avanzada -> Modelo de proceso -> Identidad cambiada de Cuenta incorporada (ApplicationPoolIdentity) a Cuenta personalizada (Mi usuario de dominio)

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

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

eliminar todos los archivos y carpetas

 Rebuild Project.
 done!

Me encontré con este problema y resultó que Windows estaba cifrando un paquete / ensamblado al que se hace referencia. Esto sucedió porque mi empresa implementó una política para requerir que la carpeta Mis documentos esté encriptada y mis soluciones de Visual Studio estaban en ese directorio.

Podría ir manualmente a las propiedades del archivo / directorio en el Explorador de Windows y deshabilitar el cifrado. Pero en mi caso, esta fue una solución temporal ya que la política de red eventualmente la volvería a cambiar. Terminé moviendo mi solución VS a otra ubicación no cifrada.

En mi caso, había copiado 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 eso, pero todavía 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 se cargó bien.

Si obtiene la DLL que no se pudo encontrar en lugar del acceso denegado, asegúrese de tener instalado el VC ++ Redistributable apropiado.

Recibí este error ejecutándose desde VS. Resultó que había abierto una solución sin ejecutar Visual Studio como administrador. Cerrar Visual Studio y ejecutarlo nuevamente como administrador y luego reconstruirlo resolvió esto por mí.

Espero que ayude a alguien.

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

1. Busque el mensaje de la excepción interna para identificar el ensamblado problemático.

2. Modifique las propiedades de seguridad del archivo de ensamblaje.

   a) Agregue la cuenta de usuario que está usando para la suplantación de identidad al grupo y los nombres de usuario.

   b) Otorgue a esa cuenta de usuario acceso completo al archivo de ensamblaje.