I get this error when I\'m using FileHelpers.dll, but my IIS is set to Full trust level so it should not be that way
That\'s the full stack trace:
We had a similar issue with Windows 2008 R2 where our application would work fine in 64bit mode but when switched to 32 bit mode would cease to function and throw the permission error, turns out, in IIS7 under Advanced Settings >> Process Model >> the "Identity" setting had been switched to "Application Pool Identity" by default and may need changed to "Network Service" to work in 32 bit mode.
We did that and now we are humming along smoothly. Figured this tidbit of info may be the reason that everyone points to folder permissions, because technically it is a folder permission issue. But the change was in IIS and not the security settings on the folders themselves.
Old question, but my answer was deleted because i have only posted a link.
maybe you will get this error: ERROR:
Could not load file or assembly ‘Microsoft.Practices.EnterpriseLibrary.Configuration.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. Failed to grant minimum permission requests. (Exception from HRESULT: 0x80131417)
This error occurs because the default trust level for local machine is Full trust, but in the network share not.
So to compile your applications remotely you have to: Go to Control Panel ->Adiministrative Tools->Microsoft .NET Framework 2.0 Configuration Open My Computer->Runtime Security Policy ->Machine >Code Groups >All Code>New (right click to appear the menu to select New )
The URL field in the next figure is the path to the shared folder , in this case, but you can choose Strong Names( for .exe or .dll) etc
Click Finish and you can compile your app!!
https://medium.com/@marcoscavaleiro/failed-to-grant-minimum-permission-requests-7245cf694ebd
I've seen this error in another instance where, for example, IIS is running an application or virtual path via a UNC path (i.e. \\svr\share\folder
). Even if Load User Profile=true
I still got the PolicyException error. It was solved by running the Code Access Security Policy Tool (Caspol.exe) to add full trust to the UNC path. Since we had both 64 bit
and 32 bit
of .Net 2.x
and .Net 4.x
, I ran it in all four environments as follows:
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\caspol.exe -pp off -m -ag 1 -url "file:////\\svr\share\folder\*" FullTrust -exclusive on
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\caspol.exe -pp off -m -ag 1 -url "file:////\\svr\share\folder\*" FullTrust -exclusive on
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\caspol.exe -pp off -m -ag 1 -url "file:////\\svr\share\folder\*" FullTrust -exclusive on
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\caspol.exe -pp off -m -ag 1 -url "file:////\\svr\share\folder\*" FullTrust -exclusive on
Some notes of caution:
.Net 4.x
be sure to enable the NetFx40_LegacySecurityPolicy to true
or the caspol.exe
commands won't work as expected.Do not add duplicate entries with caspol.exe
for a given environment. Run the commands below to view your entries:
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\caspol.exe -a -lg
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\caspol.exe -a -lg
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\caspol.exe -a -lg
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\caspol.exe -a -lg