This Monday I was trying to deploy an ASP.net website that contained the ASP.net AJAX toolkit inside to a server running Windows 2008 R2 (64 bits) and IIS 7.5. This was the first time that I had attempted to do so on such a server.
The way in which I went about copying the site to the server (which is live on the internet) was the following:
Now normally, what we tell our customers is that just doing an X-Copy on an ASP.net application inside IIS will just work – there is nothing else to do. I guess Monday mornings are a bit different. When trying to load the site I immediately had an error message stating that:
Server Error in / Application. Security Exception Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file. Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.
Now there are several ways around this problem, and this problem is NOT only limited to the AJAX Control Toolkit. I ran into the same problem today when deploying an MVC application onto another Windows 2008 R2 server. But I would like to explain a bit the root cause of the problem.
In my application from Monday morning I had just added a reference to the AjaxControlToolkit.dll that I had downloaded from the Microsoft ASP.net website directly. Visual Studio 2008 copied the .dll into the bin folder of my application following this addition.
However, the file was copied from another machine, and notably from another zone (the Internet Zone). Had I compiled the toolkit in Visual Studio along with my site, the newly generated .dll would have been in the same Zone (the My Computer Zone) as the rest of the .Net assemblies for my site. However this was not the case.
When copying the site to the server, these settings were preserved, and thus the assemblies from my website did not have the same trust level as the AjaxControlToolkit.dll that I had downloaded from the Internet. The Ajax Control Toolkit assembly had fewer privileges than the rest of my assemblies, and thus posed a problem.
In IIS 7.5, the default application pool is no longer Network Service, like in IIS 6 (that came with Windows 2003) and IIS 7 (that comes with Windows 2008), but rather a built in account called ApplicationPoolIdentity. This is even more restrictive than Network Service, in that required trust levels for .Net assemblies to be loaded inside an application pool have to be greater than what was permitted with Network Service.
The easy way out is just to go back to using Network Service as an application pool identity instead of the ApplicationPoolIdentity used by IIS 7.5. However, this undermines the new security enforcements that the IIS team has created, and kind of defeats the purpose of using IIS 7.5 as opposed to IIS 7.
The way to achieve this is to ensure that the assembly in question has the necessary privileges for the .Net Runtime to load inside the application pool when the application is started. To grant the assembly the needed trust level, the simplest way to proceed is to open a Windows Explorer and locate the assembly and then do a right click on the file.
Inside the properties window that appears you should have the same warning as highlighted in the screenshot. The solution to the problem is as simple as clicking on the Unlock button next to the warning message and all will start working as promised.
By Paul Cociuba – ASP.net Dev Support Team
Follow what I read via Linqto.me
Thank you for this infomarion. It was really usefull.
I was able to resolve the issue i was facing with one of my application.
After copying some DLL files from another computer to my computer running Windows 7 and IIS 7 - my app decided not to work. This did the trick.
Thank you very much!
Thanks so much for this blog post. I just had this and it was doing my head.
A custom DLL a quick copy to the server maybe a restart of IIS. Oh no! I got this horrible thing.
Now I don't get the extra securities section in the properties box in the GUI Of course I can use network service but.......
You say that that is the simplest way of doing this what are other ways?
Are there any more undocumented features (i feel I know a lot about IIS stuff) about the apppoolidentity?
Setting you network service is your simplest choice. The other way of getting this to work is to understand the security restrictions related to .Net assemblies. By default, all assemblies you copy off of the Internet code group - which is somewhat limited, and turn out not to be trusted by the AppPoolIdentity. Hence the other way of achieving this is to create a .Net code group of your assemblies (based on a proof like the assembly location). Then you need to grant the needed permissions to the code group, and make sure that the targeted assemblies only inherit the permissions from this code group, and don't combine permissions from other code groups they belong to.
You need to have a good understanding of .Net code groups, and this is more complicated.
Thanks very much for this info, it fixed the problem for me. I wish I had discovered it sooner!
Like the others, this issue was causing major frustration, but your solution fixed it....after a restart of IIS and IE
Thank you, Thank you, Thank you, saved me a lot of pain
Excellent Article!!! This helped me solved my problem and has been written very clear and concisely. One thing to note, once I unblocked my DLLs, I had to stop and restart IIS before it started working for me again. May not be required by everyone but make sure to give that a try if you're still getting the exception.
Thank you very much for the concise and thorough post - I only wish this post came further up in Google results. The resoultion to at least some instances of that message prior to Windows 7 / IIS 7 was very different, and I hadn't encountered the "Unblock" option yet. The solution worked perfectly.
Very usefull information with great explanation. It saved me a lot of time.
As many guys, I moved my web site from development Windows 7x64 to Web server and
in my case my first page worked ok (no Ajax aplied), but navigate to the other page (page that I have applied Ajax tool kit) failed with security exception. Your explanation gave me a clue.
It solve my problem.
The issue was that when i zip the build and unzip on the production, the permission of its dll got change.
I have to unblock it then code start running.
hi thanx for this solution
Exactly fixed! Best and great explanation!!
This solution helped me. Thank you!
Have you ever had the situation where the Unblock did not persist? We have an ASP.NET software application that is generally deployed using an msi. We have a customer that needs an update, so we would like to just replace an existing dll in the web site with a new one. I asked him to try the suggestion above and his response was: I went to the properties, clicked on the Unblock button, clicked on the Apply button, clicked on OK and still got the Security error.
I then executed the iisreset just for good measure and tried again.
Still getting the Security error. It changes when I click the Unblock but when I go back in it still has the same message, the Unblock did not persist