views:

944

answers:

4

I know this has been asked before but the answer given was a temporary hack.

We have had a site running on our live servers for some time now and we have just made some updates and deployed. Intitally the JIT runs and the site works. When the application pool is next refreshed we are receiving the following error from the webserver (IIS6).

Could not load file or assembly 'OurBusinessObjectsAssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Access is denied.

As an answer to a previous question suggested re-uploading the bin dll in question causes a rebuild and the site works again but a subsequent app pool recycle causes the same issue. What is causing this? The webserver runs many other sites fine so I don't think its a permissions issue with the asp.net temporary files and have already checked this, they seem fine.

A: 

I've had this same problem - it is to do with rights on the temporary ASP.NET folder (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files) - check that the user running as your app has rights to create and modify files in this folder, not just read rights.

JonoW
As I said I have checked permissions and they are fine. Also the old version of the site runs fine even after an app pool reset so I don't think its a permissions issue
Sheff
Hmmm odd. Have you tried running something like ProcessMon to try and profile which process and user is generating the "access denied"?
JonoW
Yeah I'm running now. The odd thing is that the file in question is showing a SUCCESS in procmon
Sheff
A: 

I have exactly the same problem. Changing file permissions did not help... did you ever solve this one?

lstanczyk
A: 

I had the exact same problem as well. It was not permission on the Temporary directory or the bin directory. It turned out to be my AV which had Access Protection enabled. Once I turned that off and registry entries were once again able to be made by the ASP.NET user, everything started working again.

A: 

I had the same issue. I was using impersonation as well. I was able to resolve it by adding the impersonating user to the local machine's administrator group?

YeahStu