Home Dashboard Directory Help
Search

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


Status: 

Closed
 as External Help for as External


2
0
Sign in
to vote
Type: Bug
ID: 622992
Opened: 11/18/2010 9:53:42 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

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,

Tyler
Details
Sign in to post a comment.
Posted by Microsoft 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.

Regards,
Marcus
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.

-Erik
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)
Sign in to post a workaround.