A veces, las aplicaciones asp.net que escribimos se ejecutan en hosts virtuales. Es posible que algunos hosts virtuales hayan establecido permisos en asp.net debido a consideraciones de seguridad, lo que hará que nuestras aplicaciones no se ejecuten correctamente.
Síntomas del problema:
Por alguna razón, asp.net no puede cargar algunos archivos dll y aparece el siguiente mensaje de error: Error del servidor en la aplicación '/'.
---------------------------------------
No se pueden adquirir los permisos necesarios .
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.Security.Policy.PolicyException: no se pueden adquirir los permisos necesarios. 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
.
[PolicyException: no se pueden adquirir los permisos necesarios.]
System.Security.SecurityManager.ResolvePolicy(Evidencia de evidencia, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& denegado, booleano checkExecutionPermission) +2738293
System.Security.SecurityManager.ResolvePolicy (evidencia de evidencia, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& denegado, Int32& securitySpecialFlags, Boolean checkExecutionPermission) +57
[FileLoadException: no se pudo cargar el archivo o ensamblado 'Microsoft.Practices.ObjectBuilder, Versión=1.0 .51205.0, Culture=neutral, PublicKeyToken=null' o una de sus dependencias No se pudieron otorgar solicitudes de permiso mínimo (Excepción de HRESULT: 0x80131417).
System.Reflection.Assembly.nLoad(Nombre de ensamblaje nombre de archivo, base de código de cadena, seguridad de ensamblaje de evidencia, sugerencia de ubicación de ensamblaje, marca de rastreo de pila y marca de pila, tiro booleano en archivo no encontrado, booleano para introspección) +0
System.Reflection.Assembly.InternalLoad(Nombre de ensamblajeRef de ensamblaje, Seguridad de ensamblaje de evidencia, StackCrawlMark y stackMark, booleano para introspección) +211
System.Reflection.Assembly.InternalLoad(Cadena de ensamblaje de cadena, Seguridad de ensamblaje de evidencia, StackCrawlMark y stackMark, booleano para introspección) +141
System.Reflection.Assembly.Load (cadena de ensamblaje) +25
System.Web.Configuration.CompilationSection.LoadAssemblyHelper (nombre del conjunto de cadena, directiva estrella booleana) +32
Análisis de problemas:
Según mi observación, el dll generado directamente por la aplicación asp.net se puede cargar normalmente, y el dll externo llamado directamente por asp.net también se puede cargar normalmente, pero otros dll externos a los que solo hace referencia el dll externo no se pueden cargar. cargado. Mi suposición es: dado que los permisos están incompletos, las DLL generadas por la propia aplicación asp.net y las DLL a las que se hace referencia directamente pueden obtener permisos mediante la herencia de permisos, mientras que otras DLL externas a las que solo hacen referencia las DLL externas no pueden heredar permisos debido a restricciones de permisos. entonces hay un problema de permisos insuficientes.
Resolución de problemas:
A través de experimentos en mi computadora, se especula que la configuración de la raíz web.config (en mi computadora su ubicación es C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG) se ha modificado en el host virtual.
La sección de configuración de permisos predeterminada de web.config es la siguiente:
<ubicación enableOverride="true">
<sistema.web>
<políticadeseguridad>
<trustLevel name="Completo" archivo de políticas="interno" />
<trustLevel name="Alto" policyFile="web_hightrust.config" />
<trustLevel name="Medio" policyFile="web_mediumtrust.config" />
<trustLevel name="Bajo" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</seguridadPolicía>
<nivel de confianza="Completo" originUrl="" />
</sistema.web>
</ubicación>
Presumiblemente la configuración modificada en el host virtual: <ubicación enableOverride="false">
<sistema.web>
<políticadeseguridad>
<trustLevel name="Completo" archivo de políticas="interno" />
<trustLevel name="Alto" policyFile="web_hightrust.config" />
<trustLevel name="Medio" policyFile="web_mediumtrust.config" />
<trustLevel name="Bajo" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</seguridadPolicía>
<nivel de confianza="Alto" originUrl="" />
</sistema.web>
</location> Primero establece enableOverride en falso, lo que impide la capacidad de redefinir permisos en el archivo web.config del usuario. Luego, definió el nivel de confianza como Alto en lugar del Completo predeterminado. Después de mis pruebas, siempre que el nivel de confianza no sea Completo, no se pueden cargar otros archivos DLL externos a los que solo hace referencia el DLL externo. Por lo tanto, recomiendo que el soporte técnico establezca la sección enableOverride en verdadero. De esta manera puedo volver a especificar los permisos en web.config.
Ejemplo: <trust level="Full" originUrl="" />
No he estudiado aps.net recientemente, por lo que no he buscado detenidamente las razones subyacentes. Tal vez mi comprensión sea incorrecta. Espero que el experto pueda decirme las razones subyacentes o corregir mis errores.