使用 ScriptManager/ToolkitManager 从 Microsoft 的 CDN 加载 AjaxControlToolkit 脚本 [英] Loading AjaxControlToolkit Scripts from Microsoft's CDN using ScriptManager/ToolkitManager

问题描述

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

I know there is another question asking the same thing, but it hasn't gotten any attention for months now: 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 在本地加载.

I've upgraded my website to .NET4, and I'm now using the scriptManager's EnableCDN="true" tag. My Ajax scripts are being referenced from the Microsoft CDN just how I expected, but I can't seem to get my AjaxControlToolkit scripts to load from the CDN. Instead they all load locally through ScriptResource.axd.

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

I know where the CDN files are located, and I know that I could reference those files every time I use a control, but I've got a lot of legacy code that loads on its own from the scriptmanager, just pulling ScriptResource.axd files.

有什么建议可以让控制工具包脚本从 CDN 加载吗?我已经有了标准的 WebForms.js 等

Any suggestions how to get the control toolkit scripts to load from the CDN? I already have the standard WebForms.js, etc.

如果有什么我可以澄清的，请告诉我，这是我正在使用的脚本管理器:(我已经尝试过 toolkitscriptmanager)

Let me know if there is anything I can clear up, here is the script manager that I'm using: (I have tried the toolkitscriptmanager)

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

推荐答案

如果程序集没有在其 WebResourceAttributes 中定义 CDN 路径，EnableCDN 将不知道去哪里.就是这样.

If an assembly does not define a CDN path in its WebResourceAttributes, EnableCDN won't know where to go. So there's that.

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

However, you can define your own CDN path if you know of a CDN that has them. I honestly don't know whether the latest ACT is on the CDN or not. If the version you are using is 40412, then yes, it is: http://www.asp.net/ajaxlibrary/CDNACT40412.ashx

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

The way you define your own path is described in my blog entry (also mentioned in another answer):
http://weblogs.asp.net/infinitiesloop/archive/2009/11/23/asp-net-4-0-scriptmanager-improvements.aspx

这是一个例子，解释如下:

Here's an example, explained below:

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，它仍然会到达那里.

Here is what is happening. First of all, there exists an assembly, lets call it Foo.dll. It contains a script as an embedded resource named "Foo.js" (the .js extension is optional). So, asp:ScriptReferences (on the page or coming from a server control) to that resource will go to ScriptResource.axd. The assembly's WebResourceAttribute for the script does not define a CDN path, so it still goes there if you turn on CdnMode.

您想解决这个问题，所以您要做的就是定位该脚本.为此，您必须参考其程序集和名称.它们一起标识脚本(如果您愿意，它是主键").AddDefinition 的第一个两个参数实现了这一点.

You want to fix that, so what you do is target that script. To do so, you have to refer to its assembly and name. Together, they identify the script (it's "primary key", if you will). The 1st two parameters to AddDefinition accomplish that.

既然您已经瞄准了它，您就可以完全重新定义成为该脚本的含义.你把它放在另一个程序集，另一个路径中，定义cdn路径..任何东西.

Now that you targetted it, you get to completely redefine what it means to be that script. You put it in another assembly, another path, define the cdn path.. anything.

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

The ResourceName and ResourceAssembly properties of the definition establish that the script really still belongs to the same assembly it came from. That might seem unnecessary if you are going to load from CDN anyway. But it does two things: (1) It will still work if you turn off CDN, and (2) it will still be able to figure out if a debug version of the resource (foo.debug.js) or any LOCALIZED versions (e.g. foo.fr-FR.js) exist in the assembly, and thereby know whether the CDN will contain that version (since it can't very well check that from the server). So it's a good idea to give the definition an owner (note that it will NOT default to the original owner if you don't specify them).

CdnPath 和 CdnDebugPath 属性是显而易见的，这里是您的最终目标.EnableCdn 现在应该可以工作了！

The CdnPath and CdnDebugPath properties are obvious, and your ultimate goal here. EnableCdn should now work!

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

I encourage you to use ScriptMapping when possible to define the details about a script and then refer to them by name instead of path. Keeps the markup simple and it's more DRY since you get to define all the details for the script in one place.

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

NOW... How do you do that with the AjaxControlToolkit?

您将不得不为工具包中的每个脚本编写这些映射之一.那不会很有趣，有几十个.不要犯为每个版本和调试脚本编写单独的错误.两者是一对，并用 1 个映射定义.其中一些也有本地化版本，但我不会理会——这些消息是针对开发人员的错误消息，无论如何都不需要本地化，因为该功能旨在本地化内容用户.

You're going to have to write one of these mappings for each and every script in the toolkit. That is not going to be fun, there are dozens and dozens of them. Don't make the mistake of writing separate ones for each release and debug script though. The two are a pair and are defined with 1 mapping. There are also localized versions of some of them, but I wouldn't bother with that -- the messages are error messages meant for developers, which really don't need to be localized anyway, because that feature is meant to localize content for end users.

有一件事——在 1 或 2 个 ACT 脚本上试一试，以确保你做对了.此外，这里还有一个更复杂的问题，我没有提到.

One thing -- try it out on 1 or 2 of the ACT scripts to make sure you got it right. Also, there's one more complexity here I didn't mention.

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

Remember when I said the Name and Assembly come together to identify a script (its "primary key")? That's true, but there's one special rule for scripts that come from System.Web.Extensions OR the so-called "AjaxFrameworkAssembly". In that case, specifying a null assembly, or using the overload where that parameter is missing altogether, is equivalent. What is a "AjaxFrameworkAssembly"? Well, System.Web.Extensions contains a little-known feature that allows an assembly to assert itself as the "AjaxFrameworkAssembly" via an assembly level attribute. Doing that means "I am the assembly that contains ms ajax scripts, you should come to me instead of System.Web.Extensions". The ACT uses this in order to 'upgrade' the scripts that are embedded in System.Web.Extensions. It has its own copies of those scripts that have a later version number. All you have to do is reference the assembly, and presto, the scripts are automatically redirected to come from there instead. The point here being, you may be able to get away with not specifying the assembly in all of those mappings. But, try it out, don't take my word for it.

这是一个 InfinitiesLoop 答案.我现在让你回到你定期安排的节目:)

This has been an InfinitiesLoop answer. I now return you to your regularly scheduled programming :)

这篇关于使用 ScriptManager/ToolkitManager 从 Microsoft 的 CDN 加载 AjaxControlToolkit 脚本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！