Antlr3.runtime access denied after updating deployed files

Question

We have an ASP.NET application that was written by a former employee that I have thus far been holding together with duct tape. The app was written with MVC, NHibernate and some other processes, none of which any of our other apps use, so I have very little idea on how to support these. To further complicate things, the original app was not built to deploy properly, so I have had to follow a set of instructions from said employee about which files to copy where to get the updates out manually. I attempted to do an update today, making a backup of the entire folder where the app resides in C:\Inetpub\wwwroot before I copied anything. After copying the files, I recycled the app pool which is usually all it takes to apply the changes. Instead I got this error:

Could not load file or assembly 'Antlr3.Runtime' or one of its dependencies. Access is denied.

Perturbed but not too upset, I simply copied my backup folder back out to the app’s folder, which should have reset it to the way it was before I attempted the update (since all I did was copy over some files). However, the error persists. I have tried re-copying several times, restarting the app pool, restarting IIS, etc., but to no avail. My Google-fu has thus far proved useless as well. I can provide the full stack trace if you think it’ll be helpful (doesn’t look useful to me). I’m really at my wit’s end because nothing else changed on the server that I can tell, and the folder has been restored to its original state (again, as far as I can tell... I have not done a file compare on each of the 100+ files).

Answer 1

This may not apply if you're not trying to get the site to run locally, but, this may help someone...

I had brought over my production server's web.config to my local workstation. I had forgotten that the production config uses impersonation. That turned out to be my problem. That user has nearly no permissions on my local workstation.

If you add the impersonation user to your local machine's IIS_WPG you can keep from having to do weird things to your Temporary ASP.NET Files permissions, etc.

Hats off to this post that led me to this truth.

My solution was to delete the impersonation line from my local web.config

Answer 2

For me the issue was with the config file.

<identity impersonate="true" userName="abc" password="xyz"/>

Here the credential given was not correct either correct that or comment out if not required.