无法加载文件或程序集或其依赖项之一。拒绝访问。这个问题是随机的，但只发生一次，就会继续下去

My solution is as follows:

I didn't find a root folder under C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files.

Google told me that it might be a permission issue against current user, then I found I have a current Identity: IIS APPPOOL in the malfunctioning server where the rest of the server has Current Identity: NT AUTHORITY\NETWORK SERVICE.

Then I changed Current Identity from IIS APPPOOL to NT AUTHORITY\NETWORK SERVICE.

From here, I found that resetting the web app rebuilds the temporary ASP.NET cache, solving the issue.

For my scenario, I found that there was a identity node in the web.config file.

<identity impersonate="true" userName="blah" password="blah">

When I removed the userName and password parameters from node, it started working.

Another option might be that you need to make sure that the specified userName has access to work with those "Temporary ASP.NET Files" folders found in the various C:\Windows\Microsoft.NET\Framework{version} folders.

Hoping this helps someone else out!

To anyone else who tried most of the solutions and still having problems.

My solution is different from the others, which is located at the bottom of this post, but before you try it make sure you have exhausted the following lists. To be sure, I have tried all of them but to no avail.

1. Recompile and redeploy from scratch, don't update the existing app. SO Answer

2. Grant IIS_IUSRS full access to the directory "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files"

   Keep in mind the framework version you are using. If your app is using impersonation, use that identity instead of IIS_IUSRS

3. Delete all contents of the directory "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files".

   Keep in mind the framework version you are using

4. Change the identity of the AppPool that your app is using, from ApplicatonPoolIdentity to NetworkService.

   IIS > Application Pools > Select current app pool > Advance Settings > Identity.

   SO Answer (please restore to default if it doesn't work)

5. Verify IIS Version and AppPool .NET version compatibility with your app. Highly applicable to first time deployments. SO Answer

6. Verify impersonation configuration if applicable. SO Answer

My Solution:

I found out that certain anti-virus softwares are actively blocking compilations of DLLs within the directory "Temporary ASP.NET Files", mine was McAfee, the IT people failed to notify me of the installation.

As per advice by both McAfee experts and Microsoft, you need to exclude the directory "Temporary ASP.NET Files" in the real time scanning.

Sources:

• McAfee Support Forum
• Microsoft Support
• Asp.Net Forum

Don't disable the Anti-Virus because it is only doing its job. Don't manually copy missing DLL files in the directory \Temporary ASP.NET Files{project name} because thats duct taping.

Had the same issue, fixed with setting the parameter "Enable 32-bit applications" to "true" (in advanced settings of iis application pool).

If you are using impersonation, be sure to give permissions, including write and modify permission to the relevant user account on the following folder:

C:\Users\[username]\AppData\Local\Temp\Temporary ASP.NET Files

I was missing the modify permission, which was why just adding the default permissions wasn't working for me.

I got this error running from VS. Turned out I'd opened a solution without running Visual Studio as admin. Closing Visual studio down and running it again as admin then rebuilding solved this for me.

Hope that helps someone.

I was not using impersonation in my case. My solution was to give full access to my project directory for the user group "IIS_IUSRS".

I had the same issue, fixed by rebuild and redeploy ALL Dependents Dll files

Check the IIS settings. I use IIS 7.5 with 32 or 64 bit compilation within the .NET framework. If you have an app that uses 32-bit mode, make sure to enable the App Pool to be able to use 32-bit instruction. Otherwise, nothing seems to work no matter how much you set the security or strong sign the DLL.

In my case it was due to the Access Protection feature of my anti-virus (McAfee). It was obviously blocking access to this file, as of such the error.

I disabled it and the solution ran. You might want to check any utility application you might have running that could be affecting access to some files.

If you still facing the issue try this:

Open your IIS Manager -> Application Pools -> select your app pool -> Advance Setting -> Under 'Process Model' set 'Load User Profile' setting as True

 Go to run  : ctrl + R
Type : %temp%

delete All files & folders

 Rebuild Project.
done!

In my case, I was using simple impersonation and the impersonation user had trouble accessing one of the project assemblies. My solution:

1. Look for the message of the inner exception to identify the problematic assembly.

2. Modify the security properties of the assembly file.

   a) Add the user account you're using for impersonation to the Group and user names.

   b) Give that user account full access to the assembly file.

I believe I wasted like 1 day on researching it and this what I have come out with.

You need to add the Impersonating user to the Debug folder of your Solution as the Framework will try to access the DLL from this location and place it in Temporary Asp.Net Folder.

So basically follow these 2 steps

1. Give permission to Temporary Asp.Net Folder under C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files and make sure the user you are adding here is the same you are using while Impersonating.

2. Add the Impersonating user to the Debug folder of your Solution YourSolutionPath .. \bin\Debug

This should work

I ran into this problem and it turned out that a referenced package/assembly was being encrypted by Windows. This happened because my company implemented a policy to require the My Documents folder to be encrypted and my Visual Studio solutions happened to be under that directory.

I could manually go into the file/directory properties in Windows Explorer and disable encryption. But in my case this was a temporary solution since the network policy would eventually change it back. I wound up moving my VS solution to another un-encrypted location.

In my case, I had copied a service from one server to another without performing a proper deployment from Visual Studio. Long story.

Anyway, I had setup all of the appropriate NTFS permissions and whatnot, but it still couldn't load the main DLL for the service.

I fixed it by renaming the corresponding service.pdb file to something else.

For example here's my bin folder: \bin\ service.dll service.dll.config service.pdb I renamed service.pdb to zzservice.pdb, and then the service.dll loaded fine.

Go to IIS -> Application Pool -> Advance Settings -> Enable 32-bit Applications

I am setting-up environment on new server. My web.config got identity node like below.When I faced with "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"

Added ccs\HJKWeb as users list of my new server.

  <authentication mode="Windows" />
<identity impersonate="true" password="******" userName="ccs\HJKWeb" />

If you get the DLL could not be found instead of access denied, make sure you have the appropriate VC++ Redistributable installed.

For me, the following hack worked; Go to IIS -> Application Pools -> Advance Settings -> Process Model -> Identity Changed from Built-in Account (ApplicationPoolIdentity) to Custom Account (My Domain User)

In my case Users with read access had to be added to the folder permissions. I removed them by accident. COMPUTER\Users