Could not load file or assembly 'AjaxControlToolkit'

Could not load file or assembly 'AjaxControlToolkit' or one of its dependencies.:

Here's what I did to resolve this under VS2008 (its probably very similar under VS2005):

First, on any project where I'm using dlls, I always create a dll folder to hold them.

I never rely on the bin folder for references (since that would be cleared out when running a clean operation and most source control programs do not include the bin file when checking in/out) or on local copies of the dll (c:\ajax\2.0\bin\ajaxcontroltoolkit.dll). Sure, the build operation puts a copy there but thats its job--leave the bin file to the build script.

'AjaxControlToolkit' or one of its dependencies.

If you ever work on your code somewhere else, publish it to another machine, or hand it off to someone else; you don't have to worry about whether the new machine has its ajaxcontroltoolkit.dll installed in the same location on its hard drive as yours.

As a side note, under the properties -> advanced for the dll, I have a build action set to content and a copy to output directory set to do not copy.

Second, I go into the references, remove any current ajaxcontroltoolkit references (or any other special dlls that I was using and am moving to the dll folder), and add the dll references back in pointing to the copies in my dll folder.

Thirdly, if I'm going to be using something like the ajaxcontroltoolkit on most of my pages, I go ahead and throw the following into the web.config file so I dont have register statements on every page:

<system.web>

<pages>

</controls>

<pages>

</assemblies>

</compilation>

</system.web>

</configuration>

Hope this helps, it took me a while to get it right

If this is an intermittent problem for you (ie, it works for a bit after a build and then you get a parser error), try stopping and starting IIS. In my case, the ajaxcontroltoolkit that the build script had placed in the bin folder was being replaced with an earlier verison of the toolkit. Restarting IIS seems to have fixed this. Since doing this, my version in the bin folder has not reverted to 1.16xxx, it stays a 1.19xxx and I don't have any more frustrating errors.