I know that in order to use most of the controls from the Ajax Control Toolkit, you need to include the ToolkitScriptManager control on your page, and it must be the Toolkit script manager, and not the standard script manager because the extended toolkit version contains extra (java)scripts which enable the controls to work and communicate properly.
My problem is that I keep coming across projects at work from other developers where they used the standard ASP ScriptManager control, and added toolkit controls without switching over to the ToolkitScriptManager. I would have expected these projects to not debug properly, yet they are currently somehow working in test and production environments, and they do not actually break until I download them onto my freshly loaded dev environment from source control.
When someone asked me "Why do we need to replace these controls? They're working everywhere else." I could only shrug my shoulders, I have no idea why other projects are working with regular script managers.
As a side note, problems like this are what are pushing me into becoming a JQuery guy instead of a ACT guy.
Here is a question to answer since this is a Q&A site and not a discussion site: "How is it possible to run the ACT controls without an ACT script manager?" Personally, I would point to a glitch in Visual Studio of some kind, but I want to know if anyone else knows more.
ToolkitScriptManager inherits from ScriptManager and extends/improves its functionality.
You may safely substitute ToolkitScriptManager with ScriptManager just so long as you are not using any advanced feature provided by the ToolkitScriptManager.
What are those supposedly advanced feature differences you ask?
TMI Alert: MS actually recommends replacing ToolkitScriptManager in certain instances if you are suffering from Out Of Memory exceptions and there are also a high number of System.Web.FileMonitorTarget objects in existence. These objects are used to check and see if the page was modified (you can see how it relates to AJAX), but these objects should go away and not be maintained.
For some reason, if you're using the ToolkitScriptManager, there are instances where FileMonitorTarget objects just don't go away and end up contributing to server memory problems, but neither I nor they fully understand why replacing the ToolkitScriptManager with ScriptManager actually helps in these scenarios, but just so long as it works, we won't continue to ask questions...