Solution to "Could not load file or assembly or one of its dependencies. Access is denied"


This is one of the most irritating build errors a developer might see, especially while setting up an existing .NET application on a fresh machine. I have found one solution that works always. Go to “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files” ( Modify the framework version, root directory etc according to your environment. ) Now, right-click and open up the Security tabs for this folder. Grant “Full control” to the ‘users’ group. (Modify will also work, thought I didn’t try it out) However, it this is a security problem for your environment to grant full control to all users in Users group, another Solution could be to put the concerned assemblies lo GAC which I avoided as it was not  logical to put the assemblies into GAC in my scenario. Hope this helps.

Comments (7)

  1. Thogek says:

    Good idea, wish I’d thought of it.  Unfortunately, in my specific case (where I’m getting the error message in the title above), this had no effect.  🙁

    I have the feeling that there are multiple issues that can lead to this symptom, and I seem to be stumbling across all of ’em in the last couple of weeks…

  2. Mafioso says:

    Dear sayangh

    I have been facing this problem for a while , and suddenly i have found your solution …. am gonna try it and see what happens …

    Thank you in advance …

  3. lamplove says:

    Trying to convert a project to VS2005 and running into this error using a dev box with multiple deployment servers…this worked for me. TX!

  4. serious says:

    I was experiencing this issue because I had set my code to impersonate a user, but that user account hadn’t been added to the computer I develop on.

  5. serious says:

    I was experiencing this issue because I had set my code to impersonate a user, but that user account hadn’t been added to my development box.

  6. msdnabb says:

    Thanks for the post. got me in the right direction.

    Further to the article (and what @serious mentioned),

    adding your impersonate user to the IIS_WPG on the local machine should solve the problem. It grants your impersonate user the correct permissions on the server file system without having to modify the folder security and open up control to large numbers of users.

    For more info check out: http://msdn.microsoft.com/en-us/library/kwzs111e.aspx