EnableCdn Does Not Link to the CDN for MicrosoftAjax.js When Using the Ajax Control Toolkit 40412 - by tcarver

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 622992 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 11/18/2010 9:53:42 AM
Access Restriction Public


Ajax Control Toolkit 40412 seems to be using its own customized version of MicrosoftAjax.js and MicrosoftAjaxWebForms.js. Toolkit's version is 4.1.40412.2, while the version that come with ASP.NET Ajax 4 is 4.0.30205.0, and the Toolkit does NOT work with the ASP.NET Ajax 4 version. By default when using the toolkit the version is swapped to the toolkit's version.

While the ASP.NET Ajax 4 version is hosted on the CDN (http://www.asp.net/ajaxlibrary/CDNAjax4.ashx) the version with the Toolkit is not (http://www.asp.net/ajaxlibrary/CDNACT40412.ashx), which doesn't make any sense because all the other files are hosted. Therefore, a CDN version of MicrosoftAjax.js and MicrosoftAjaxWebForms.js is UNAVAILABLE when using the Ajax Control Toolkit 40412.

The new attribute EnableCdn="true" is of course rendered completely useless when using the Ajax Control Toolkit because the idea is that the MicrosoftAjax.js and MicrosoftAjaxWebForms.js files would then be linked by references to the CDN. This does not happen with the Toolkit because as described the Toolkit replaces the those files with its own. I was very surprised to find out that all my excitement about having CDN support was made void when I included the Toolkit in my project.

A possible solution would be to add the following to the global.asax.cs file:

     void Application_Start(object sender, EventArgs e)
            ScriptManager.ScriptResourceMapping.AddDefinition("MicrosoftAjax.js", new ScriptResourceDefinition
                  Path = "~/Scripts/MicrosoftAjax.js",
                  DebugPath = "~/Scripts/MicrosoftAjax.debug.js",
                  CdnPath = "http://ajax.microsoft.com/ajax/4.0/1/MicrosoftAjax.js",
                  CdnDebugPath = "http://ajax.microsoft.com/ajax/4.0/1/MicrosoftAjax.debug.js"

This of course is not helpful as the files, as stated earlier, for the toolkit are NOT on the CDN.

Thanks in advance for any help in solving this issue,

Sign in to post a comment.
Posted by Damian [MSFT] on 8/23/2012 at 5:08 PM
The Ajax Control Toolkit is an Open Source project maintained independently at http://ajaxcontroltoolkit.codeplex.com. I suggest you try updating to a later version and if the issue remains log an issue on the project site.
Posted by Marcus Lundberg on 3/30/2012 at 12:36 AM
I agee that this is still an issue and needs to be addressed.

Posted by jhewett on 7/22/2011 at 4:48 PM
Erik (or anyone else that's working on these issues) -- You need to re-read the issue description. This issue is not resolved, and it's most certainly not an "unable to repro".

Your test is loading "WebForms.js" from an OLD VERSION of the MS Ajax library -- version 3.5, to be specific. The issue as described by Tyler is that NONE of the MicrosoftAjax*.js files from version 4.1.40412 are being loaded from any of the CDN URL's (http://ajax.microsoft.com, http://ajax.aspnetcdn.com).

Loading a JS file from the OLD VERSION -- http://ajax.microsoft.com/ajax/4.0/1/WebForms.js -- is NOT THE SAME THING as loading JS files from the NEW VERSION.

Jerry H.
Posted by Microsoft on 12/9/2010 at 5:09 PM
Thank you for submitting your suggestion on Connect!

I was unable to repro this issue. I created a new web app, added a reference to AjaxControlToolkit.dll (40412) and added an editor to the page (and a script manager), then set script manager to EnableCDN="true" and noted in the rendered page a reference to the http://ajax.microsoft.com/ajax/4.0/1/WebForms.js script file.

Posted by Microsoft on 11/18/2010 at 10:22 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)