Manchmal werden die von uns geschriebenen asp.net-Anwendungen auf virtuellen Hosts ausgeführt. Einige virtuelle Hosts haben möglicherweise aus Sicherheitsgründen Berechtigungen für asp.net festgelegt, was dazu führt, dass unsere Anwendungen nicht ordnungsgemäß ausgeführt werden.
Problemsymptome:
Aus irgendeinem Grund kann asp.net einige DLL-Dateien nicht laden und die folgende Fehlermeldung wird angezeigt: Serverfehler in der Anwendung „/“.
---------------------------------------------
Erforderliche Berechtigungen können nicht erworben werden .
Beschreibung: Während der Ausführung der aktuellen Webanforderung ist eine nicht behandelte Ausnahme aufgetreten. Überprüfen Sie den Stack-Trace auf weitere Informationen zum Fehler und zur Ursache im Code.
Ausnahmedetails: System.Security.Policy.PolicyException: Erforderliche Berechtigungen können nicht erworben werden .
Quellfehler:
Während der Ausführung der aktuellen Webanforderung wurde eine nicht behandelte Ausnahme generiert. Informationen zum Ursprung und Ort der Ausnahme können mithilfe des Ausnahme-Stack-Trace identifiziert werden
:
[PolicyException: Erforderliche Berechtigungen können nicht erworben werden.]
System.Security.SecurityManager.ResolvePolicy(Beweisnachweis, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& denied, Boolean checkExecutionPermission) +2738293
System.Security.SecurityManager.ResolvePolicy(Beweisbeweis, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& denied, Int32& securitySpecialFlags, Boolean checkExecutionPermission) +57
[FileLoadException: Datei oder Assembly 'Microsoft.Practices.ObjectBuilder, Version=1.0' konnte nicht geladen werden .51205.0, Culture=neutral, PublicKeyToken=null‘ oder eine seiner Abhängigkeiten konnte keine Mindestberechtigungsanforderungen gewähren (Ausnahme von HRESULT: 0x80131417).
System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, EvidenceassemblySecurity, 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(StringassemblyString, EvidenceassemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +141
System.Reflection.Assembly.Load(StringassemblyString) +25
System.Web.Configuration.CompilationSection.LoadAssemblyHelper(StringassemblyName, Boolean starDirective) +32
Problemanalyse:
Nach meiner Beobachtung kann die direkt von der asp.net-Anwendung generierte DLL normal geladen werden, und die von asp.net direkt aufgerufene externe DLL kann ebenfalls normal geladen werden, andere externe DLLs, auf die nur von der externen DLL verwiesen wird, jedoch nicht geladen. Meine Vermutung ist: Da die Berechtigungen unvollständig sind, können von der asp.net-Anwendung selbst generierte DLLs und direkt referenzierte DLLs Berechtigungen durch Vererbung von Berechtigungen erhalten, während andere externe DLLs, auf die nur von externen DLLs verwiesen wird, aufgrund von Berechtigungsbeschränkungen keine Berechtigungen erben können. Es besteht also das Problem unzureichender Berechtigungen.
Problemlösung:
Durch Experimente auf meinem Computer wird spekuliert, dass die Einstellungen der Root web.config (auf meinem Computer ist der Speicherort C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG) auf dem virtuellen Host geändert wurden.
Der Abschnitt mit den standardmäßigen web.config-Berechtigungseinstellungen lautet wie folgt:
<locationallowOverride="true">
<system.web>
<Sicherheitsrichtlinie>
<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>
Vermutlich die geänderten Einstellungen auf dem virtuellen Host: <locationallowOverride="false">
<system.web>
<Sicherheitsrichtlinie>
<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> Er setzt „allowOverride“ zunächst auf „false“, wodurch verhindert wird, dass Berechtigungen in der web.config des Benutzers neu definiert werden können. Anschließend definierte er die Vertrauensstufe als „Hoch“ anstelle der Standardeinstellung „Voll“. Nach meinen Tests können andere externe DLLs, auf die nur von der externen DLL verwiesen wird, nicht geladen werden, solange die Vertrauensstufe nicht „Voll“ ist. Daher empfehle ich dem technischen Support, den Abschnitt „allowOverride“ auf „true“ zu setzen. Auf diese Weise kann ich Berechtigungen in web.config neu angeben.
Beispiel: <trust level="Full" originUrl="" />
Ich habe aps.net in letzter Zeit nicht studiert, daher habe ich nicht sorgfältig nach den zugrunde liegenden Gründen gesucht. Vielleicht ist mein Verständnis falsch. Ich hoffe, der Experte kann mir die zugrunde liegenden Gründe nennen oder meine Fehler korrigieren.