Todays gotcha: Windows 7 assembly blocking
Yesterday I was playing with our new build server, trying to get it to run my fully-functional unit tests with code coverage analysis. Why that didn’t work is a different story, but in the progress of changing project settings and checking in updates something strange happened. Suddenly my local web site stopped working.
The error message
My local copy of the site with the web root set to my working folder for the project suddenly refused to start, prompting me with the yellow screen of death and this cryptic error message:
| 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. … Mapper.CreateMap<OtherProject.ClientProxies.Core.Person, MyProject.ExternalDataAccess.DTO.Person>(); … |
(In the example above, I removed all the lines except the one where it indicated failure, which was the first line of my AutoMapper bootstrapper.)
Troubleshooting
I started troubleshooting blindly, rolling back the project, cleaning, rebuilding, checking that all dependencies were copied on build etc. etc., but all looked fine. I then checked the trust settings of IIS in case they had been messed up. No luck there either.
After some time googling I decided to follow a vague tip about checking the properties of all assemblies that are references or other dependences. BOOM – at the very bottom of the properties dialog of the AutoMapper assembly was this message:
This file came from another computer and might be blocked to help protect this computer.
Why on earth Windows had suddenly decided that the assembly came from another computer (and what does that mean, don’t most assemblies come from other computers?) I had no Idea about. But luckily it left me the option to unblock the assembly. After doing so, and after deleting the copy in the bin folder letting the rebuild take a fresh copy the unblocked assembly and finally restarting IIS, the site came back to life.
This typically happen if you download files using IE, and the site is not among the Trusted Sites (not many are).
I've seen this happen several times, when people deploy to production servers and download the new files by zipping them, sending an email to themselves, and open the email through the browser. The zip file has this blocked flag, and when using Windows Explorer to unzip, all files in the zip fill also be blocked (using 7zip or Winrar remove the block flag when unpacking.) I always check and remove that flag before I unzip anything.
This is especially nasty when you deploy only one new .dll, cause the error message may vary, depending on how that dll is loaded into memory.
Agreed, it's very deceitful because there's no special error message for this type of "security breach", it will simply depend on the first time anything from that assembly is requested. In my case the clues pointed clearly to AutoMapper, but It might as well have been something deeper within the call stack there. It should really have its own Exception type.
And the ways of assembly blocking must indeed be mysterious, because in my case the AutoMapper dll probably never even left the bin folder. My copy task in the project is set to only replace the files if they have been changed, and I never cleared the bin folder so a fresh copy shouldn't have occurred either. Absolutely no web, email or zipping involved.