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).

Garrettgarrick

I got it working again by blowing the entire folder away and redeploying the whole app, rather than just updating it or restoring it from backup. Still no idea why re-copying my backup folder wouldn't restore it... – Garrettgarrick

Read this: westdiscgolf.blogspot.com/2012/06/… – Gratify

To anyone else still having problems, this link might be of interest https://mcmap.net/q/235314/-could-not-load-file-or-assembly-or-one-of-its-dependencies-access-is-denied-the-issue-is-random-but-after-it-happens-once-it-continues – Perionychium

@Garrettgarrick That worked for me also. After uggrading to .NET 4.7.2 from 4.7 and updating lots of nuget packages I was getting different error messages with every refresh (the above Antlr3 error was one of them), so thanks to your suggestion I deleted as much stuff on the (Azure web app) server as I thought I could get away with, then redeployed. Then I started getting sensible, consistent error messages. I then realised I had to remove old binding redirects from my web.config file, which I did, and everything worked again. – Tour

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

Ivonneivor

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.

Desiccated

Answer 3

Could you check permissions for IIS user in your wwwroot folder and “Temporary ASP.NET Files” C:\WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET? If permissions alright try clear asp.net temp folder and run your application again(and check permissions on this folder again).

Bad

Answer 4

Just fixed this one. A new reason:

The ACLs on the deployment folder had become messed up (eg. bin folder showing, in Explorer's security advanced view, inheriting permissions not from its parent, but its parent's parent).

A quick reset permissions from the site's root and all started working again.

Exaggeration