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

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?

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.

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..)

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.

I got this error message (although another dll file) when I reinstalled my ASP.NET application on a new Windows Server 2008 machine. I searched for a solution to this for hours, trying absolutely everything, but to no avail. Until I deactivated McAfee antivirus. When I did, everything worked like a charm.

Not 100% sure why this worked, but in the appropriate Temporary ASP.Net Files directory (located at: C:\Windows\Microsoft.NET\Framework64\v4.0.21006\Temporary ASP.NET Files[projectName]) I manually coppied the AjaxControlToolkit.dll.

I was then presented with additional DLLs that were missing, but upon manually copying them to this location also I was able to resolve these issues. Doesn't seem like the best answer, but it ended up working for me.

I tried giving my impersonated user full rights to the Temporary ASP.NET Files folder, but that didn't work. I remember in the past when I got this error that it did the trick.

I know the question poster tried this but it worked for me when I removed/added the AjaxToolKit in visual studio. I suggest trying everything he has done first. I hope this helps someone.

You can try this: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ . Just clean up all the folders and files from inside this folder and compile ur application. Happy coding!

Odd error. Is anything in your web.config file pointing to the AjaxControlToolkit with a public key token or other assembly specifications provided? That has happened to me, where a value changed or I changed from a reference in the GAC to a local reference...

HTH.

I was facing the same issue. After a lot of research I found out that I was using impersonation in the config file. I had to change the impersonation ID to a different user that was local to the server and it resolved the issue immediately.

Inspect the DLL's properties. If it states somewhere that "this file came from another computer", click the checkbox and "apply", to lift restrictions Windows has put in place.

Remember to also open "Visual Studio" with "Run as administrator" using context-menu [right-click].