使用 ScriptManager/ToolkitManager 从 Microsoft 的 CDN 加载 AjaxControlToolkit 脚本

我知道还有另一个问题在问同样的事情，但几个月来它还没有引起任何关注：https://stackoverflow.com/questions/3786088/how-to-force-ajax-control-toolkit-scripts-loading-from-cdn

我已将网站升级到 .NET4，现在使用 scriptManager 的 EnableCDN="true" 标记。我的 Ajax 脚本按照我的预期从 Microsoft CDN 引用，但我似乎无法从 CDN 加载我的 AjaxControlToolkit 脚本。相反，它们都通过 ScriptResource.axd 在本地加载。

我知道 CDN 文件所在的位置，并且我知道每次使用控件时都可以引用这些文件，但是我有很多从 scriptmanager 自行加载的遗留代码，只需提取 ScriptResource.axd 文件。

对于如何从 CDN 加载控制工具包脚本有什么建议吗？我已经有了标准的 WebForms.js 等。

如果有什么我可以解决的，请告诉我，这是我正在使用的脚本管理器：（我已经尝试过 toolkitscriptmanager）

<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="true" 
EnableCdn="true" EnableScriptLocalization="false" 
LoadScriptsBeforeUI="false" EnableViewState="false" />

如果程序集未在其 WebResourceAttributes 中定义 CDN 路径，则 EnableCDN 将不知道该去哪里。所以就是这样。

但是，如果您知道有 CDN 路径，则可以定义自己的 CDN 路径。老实说我不知道​​最新的ACT是否在CDN上。如果您使用的版本是40412，那么是的，它是：http://www.asp.net/ajaxlibrary/CDNACT40412.ashx

我的博客文章中描述了您定义自己的路径的方式（在另一个答案中也提到了）：
http://weblogs.asp.net/infinitiesloop/archive/2009/11/23/asp-net-4-0-scriptmanager-improvements.aspx

这是一个示例，解释如下：

void Application_Start(object sender, EventArgs e) {
    ScriptManager.ScriptResourceMapping.AddDefinition("Foo.js", typeof(FooControl).Assembly, new ScriptResourceDefinition {
        ResourceName = "Foo.js",
        ResourceAssembly = typeof(FooControl).Assembly,
        CdnPath = "http://yadda-yadda/foo.js",
        CdnDebugPath = "http://yadda-yadda/foo.debug.js",
    });
}

这就是正在发生的事情。首先，存在一个程序集，我们将其称为 Foo.dll。它包含一个脚本作为名为“Foo.js”的嵌入式资源（.js 扩展名是可选的）。因此，对该资源的 asp:ScriptReferences（在页面上或来自服务器控件）将转到 ScriptResource.axd。脚本的程序集的 WebResourceAttribute 未定义 CDN 路径，因此如果您打开 CdnMode，它仍然会到达那里。

您想解决这个问题，所以您要做的就是针对该脚本。为此，您必须引用其程序集和名称。它们一起识别脚本（如果您愿意的话，它是“主键”）。 AddDefinition 的前两个参数可以实现这一点。

现在您已经确定了目标，您可以完全重新定义该脚本的含义。你把它放在另一个程序集中，另一个路径，定义 cdn 路径..任何东西。

定义的 ResourceName 和 ResourceAssembly 属性确定脚本实际上仍然属于它所来自的同一程序集。如果您无论如何都要从 CDN 加载，这似乎是不必要的。但它做了两件事：(1) 如果您关闭 CDN，它仍然可以工作，(2) 它仍然能够确定资源的调试版本 (foo.debug.js) 或任何本地化版本 (例如 foo.fr-FR.js）存在于程序集中，从而知道 CDN 是否包含该版本（因为它无法很好地从服务器检查该版本）。因此，最好为定义指定一个所有者（请注意，如果您不指定原始所有者，它不会默认为原始所有者）。

CdnPath 和 CdnDebugPath 属性很明显，也是您的最终目标。 EnableCdn 现在应该可以工作了！

我鼓励您尽可能使用 ScriptMapping 来定义有关脚本的详细信息，然后通过名称而不是路径引用它们。保持标记简单并且更加干燥，因为您可以在一处定义脚本的所有详细信息。

现在...如何使用 AjaxControlToolkit 做到这一点？

您必须为工具包中的每个脚本编写这些映射之一。这不会很有趣，有几十个。不过，不要错误地为每个版本和调试脚本编写单独的脚本。两者是一对并且用1个映射来定义。其中一些也有本地化版本，但我不会为此烦恼——这些消息是为开发人员准备的错误消息，实际上并不需要本地化，因为该功能旨在本地化最终的内容用户。

有一件事 - 在 1 个或 2 个 ACT 脚本上进行尝试，以确保您做对了。另外，还有一个我没有提到的复杂性。

还记得我说过名称和程序集一起来识别脚本（它的“主键”）吗？确实如此，但对于来自 System.Web.Extensions 或所谓的“AjaxFrameworkAssembly”的脚本有一个特殊规则。在这种情况下，指定空程序集或使用完全缺少该参数的重载是等效的。什么是“AjaxFrameworkAssembly”？那么，System.Web.Extensions 包含一个鲜为人知的功能，该功能允许程序集通过程序集级别属性将自身断言为“AjaxFrameworkAssembly”。这样做意味着“我是包含 ms ajax 脚本的程序集，你应该来找我而不是 System.Web.Extensions”。 ACT 使用它来“升级”嵌入在 System.Web.Extensions 中的脚本。它有自己的那些具有更高版本号的脚本的副本。您所要做的就是引用程序集，然后脚本就会自动重定向到来自那里。这里的要点是，您也许可以不必在所有这些映射中指定程序集。但是，尝试一下，不要相信我的话。

这是 InfinitiesLoop 的答案。我现在让您回到定期安排的节目:)