But what really worked for me was granting full access (to the userName specified in impersonate), to the Temporary ASP.NET Files" folder found in C:\Windows\Microsoft.NET\Framework{version} (or Framework64).
The identity might also be stored in the Web Site Application Pool Settings, in IIS.
Make sure your nuget package is correctly installed, with the correct version. If nothing else works, then just try re-adding the reference from a local folder and setting it to Copy Local.
My problem was that the latest version of WebGrease installs version 3.4.1.9004 of Antlr.
Once I installed WebGrease and then updated Antlr to version 3.5.0.2, the error went away.
In a project I had reference to WebGrease, but there was not corresponding element in packages.config. I remove the reference from project, because I don't need it anymore. It works now.
Just in case this helps someone.
I had this problem with an MVC 5 Application. Deleting Antlr3.Runtime.dll from the bin directory and re-building fixed the issue.
what worked for me was removing the identity = true from my webconfig (under the system.web properties) and build the solution again and publish it again (if needed) and it worked like a charm!
My problem ended up being caused by a change to the mapped drives in our Group Policy. My solution has the tempDirectory setting set in the Web.config to use a RAM drive setup as my Z: drive. Apparently they started using the Z: drive and the DLLs were getting copied to tempDirectory like normal, but then I think they were being deleted by a process on the remote server (Virus scan probably). I was only able to figure this out by using Process Monitor and filtering for Antlr and seeing that it was looking in a network location for the DLLs.
With only targetFramework="4.6" instead of 4.6.1
Web site displays without errors.
Next I changed again to targetFramework="4.6.1" and restart server.
Everything remains Ok.
If you're using impersonation. The answer is to give permission for the user that you're impersonating access to the following folders :
C:\Windows\Microsoft.NET\Framework[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files
Your site directory.
also you might need to create folder as the following :
C:\Windows\Microsoft.NET\Framework\[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files\[Application-Name-Goes-Here]
But try the previous first, it worked for me.
Those two changes for granting the impersonated user permission to be able to save the temp data, and pull the dll files, and any needed files from the directories
Update, For windows 10 This is the solution that worked for me
We will do both steps, but Instead of
C:\Windows\Microsoft.NET\Framework[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files
Write %TEMP% into the file explorer, and give permission for the user that you're impersonating access to the following folder:
C:\Users\[UserName]\AppData\Local\Temp\Temporary ASP.NET Files
I just faced this issue and tried above mentioned solutions but nothing worked for now
I had to delete it's dll from bin floder and rebuild and then delete all releated files from packages folder and restore packages using package manager console
In my case, when I cloned a project, Visual studio 2019 replaced a spaces character with '% 20' in the project's path.
Then, when VS tried to find the nugget packages, it could not find the correct path.