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

小编典典

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

ajax

我知道还有另一个问题在问同样的事情，但几个月来一直没有引起任何关注：https：//stackoverflow.com/questions/3786088/how-to-force-ajax-control-toolkit-
scripts-loading -从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" />

阅读 415

2020-07-26

共1个答案

小编典典

如果程序集未在其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）还是任何LOCALIZED版本（例如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的答案。我现在将您带回您定期安排的节目:)

2020-07-26