Если сборка не определяет путь CDN в своих WebResourceAttributes, 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. Теперь я возвращаюсь к вашему регулярному программированию:)