Could not load file or assembly 'AjaxControlToolkit' after upgrade to .net 4.0

Question

I have a web application that I am attempting to upgrade to .net 4.0.

I took the application and opened it via Visual Studio 2010 Beta 2 and selected the upgrade path for that application. The application uses the AjaxControlToolkit. Now that the upgrade is complete when I attempt to access a page I get the error message: "Could not load file or assembly 'AjaxControlToolkit' or one of its dependencies. Access is denied."

I've tried:

• Restarting my machine
• Clean Solution
• Removing all files in Temporary ASP.Net Files
• Relaxing permsissions (added Everyone with Full Control) on the Bin directory, the Temporary ASP.Net Files directory
• Removing and readding the reference to the AjaxControlToolkit DLL

The related web.config entries for the AjackControlToolkit are:

<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
  <controls>
    <add tagPrefix="ajaxToolkit" namespace="AjaxControlToolkit" assembly="AjaxControlToolkit"/>
  </controls>
</pages>

Any ideas as to what is occuring here/how I can fix this issue?

Answer 1

I had a similar problem but was able to resolve by granting full rights to the "Temporary ASP.NET Files" folder for my impersonation identity.

Answer 2

I realize there's already an accepted answer, but for anyone else coming to this page via a search on the error code....

Review the permissions of the user that you're trying to impersonate.

In my situation, I was only getting the error on my development machine, rather then on our staging or deployment servers. (For while I got around this by removing the 'identity' node from config in my dev environment and just adding the line in post-build so it wasn't a problem for anyone other than me..

In my environment we have a specific user that all our web apps impersonate when running. I had created the user account, but hadn't explicitly set its account permissions. When I added the user as an Administrator on my dev machine, this problem went away completely. (Not ideal, I know, but it "works for me", and has minimal harm since that user account is locked down on our 'real' servers anyways..)

Answer 3

I think the post about the Temp files in C:\Windows\Microsoft.NET\Framework64\v4.0.21006\Temporary ASP.NET Files[projectName] was on the right track.

I solved the problem by editing permissions to be sure that the ASP Impersonating user (found in the security section of IIS as the Anonymous user that the app should use when allowing anonymous access) had the proper security to the directory.

Solved the problem... Access Denied ussually points to a permissions issue.