Sometimes the asp.net applications we write run on virtual hosts. Some virtual hosts may have set permissions on asp.net due to security considerations, which will cause our applications to fail to run properly.
Problem symptoms:
For some reason, asp.net cannot load some dll files, and the following error message appears: Server Error in '/' Application.
---------------------------------------------
Required permissions cannot be acquired .
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Security.Policy.PolicyException: Required permissions cannot be acquired .
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[PolicyException: Required permissions cannot be acquired.]
System.Security.SecurityManager.ResolvePolicy(Evidence evidence, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& denied, Boolean checkExecutionPermission) +2738293
System.Security.SecurityManager.ResolvePolicy(Evidence evidence, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& denied, Int32& securitySpecialFlags, Boolean checkExecutionPermission) +57
[FileLoadException: Could not load file or assembly 'Microsoft.Practices.ObjectBuilder, Version=1.0 .51205.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Failed to grant minimum permission requests. (Exception from HRESULT: 0x80131417)]
System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) +0
System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +211
System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +141
System.Reflection.Assembly.Load(String assemblyString) +25
System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +32
Problem analysis:
According to my observation, the dll generated directly by the asp.net application can be loaded normally, and the external dll directly called by asp.net can also be loaded normally, but other external dlls that are only referenced by the external dll cannot be loaded. My guess is: Since permissions are incomplete, DLLs generated by the asp.net application itself and directly referenced DLLs can obtain permissions through inheritance of permissions, while other external DLLs that are only referenced by external DLLs cannot inherit permissions due to permission restrictions. , so there is a problem of insufficient permissions.
Problem solving:
Through experiments on my computer, it is speculated that the settings of the root web.config (on my computer its location is C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG) have been modified on the virtual host.
The default web.config permissions setting section is as follows:
<location allowOverride="true">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</securityPolicy>
<trust level="Full" originUrl="" />
</system.web>
</location>
Presumably the modified settings on the virtual host: <location allowOverride="false">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</securityPolicy>
<trust level="High" originUrl="" />
</system.web>
</location> He first sets allowOverride to false, which prevents the ability to redefine permissions in the user's web.config. Then, he defined the trust level as High instead of the default Full. After my testing, as long as the trust level is not Full, other external dlls that are only referenced by the external dll cannot be loaded. Therefore, I recommend that tech support set the allowOverride section to true. This way I can re-specify permissions in web.config.
Example: <trust level="Full" originUrl="" />
I haven't studied aps.net recently, so I haven't carefully looked for the underlying reasons. Maybe my understanding is wrong. I hope the expert can tell me the underlying reasons or correct my mistakes.