WebResource Hell - ресурс не найден

Отмечено javascript файл как "Встроенный ресурс" Добавлен атрибут WebResource для моего класса ************ Теперь я пытаюсь вывести встроенный javascript на мою главную страницу. Все, что я получаю, это "Веб-ресурс не найден" из URL-адреса веб-ресурса.

Название сборки проекта:

CompanyProduct

Пространство имен по умолчанию проекта:

Company.Product.Web

Файл Javascript расположен: Библиотека /navigation.js

************:

[assembly: WebResource("CompanyProduct.Library.navigation.js", "text/javascript")]

Код на главной странице:

Page.ClientScript.RegisterClientScriptInclude("NavigationScript", Page.ClientScript.GetWebResourceUrl(this.GetType(), "CompanyProduct.Library.navigation.js"));

Ошибка сервера в приложении "/".

Ресурс не найден.

Описание: HTTP 404. Ресурс, который вы ищете (или его зависимости), мог быть удален, если его имя было изменено или временно недоступно. Пожалуйста, просмотрите следующий URL-адрес и убедитесь, что оно написано правильно. Запрошенный URL:/WebResource.axd Информация о версии: Microsoft.NET Framework Version: 2.0.50727.1433; Версия ASP.NET: 2.0.50727.1433
14 ответов

Вместо this.GetType() получить тип из сборки, содержащей ресурс.. ie:

typeof(Company.Product.Web.Library.Class1)

Это работает?


Пришел к той же проблеме сегодня. Проблема заключается в том, что AssemblyResourceLoader использует сборку, содержащую тип, предоставляемый методу GetWebResourceUrl (первый параметр), который в вашем случае представляет собой динамически созданный сборник для главной страницы (.master) и не содержит ресурс, который вы ищете, Я предполагаю, что ваш файл ресурсов включен в ту же сборку, что и основная основная страница (файл .master.cs), после чего вы можете использовать typeof для получения экземпляра Type

Page.ClientScript.RegisterClientScriptInclude( "NavigationScript", Page.ClientScript.GetWebResourceUrl( typeof(MyMasterPage), "CompanyProduct.Library.navigation.js"));

где MyMasterPage - это имя вашей главной страницы

Похоже, что также можно использовать любой другой тип, объявленный в той же сборке, где встроен ресурс.


Я думаю, вы хотите, чтобы полные пути основывались на пространстве имен, а не на сборке; Поэтому везде, где у вас есть "CompanyProduct.Library.navigation.js", замените его на "Company.Product.Web.Library.navigation.js". Кроме того, существует метод Page.ClientScript.RegisterClientScriptResource(), который делает то, что вам нужно в одном методе (в отличие от использования RegisterClientScriptInclude (GetWebResourceUrl()).


Для тех, кто использует VB - есть разница в поведении между компилятором VB и компилятором С#.

В VB встроенный ресурс должен быть на корневом уровне вашего проекта. Когда я посмотрел на сгенерированную сборку с ILDASM, я обнаружил, что имя встроенного ресурса NEVER включает имена любых подпапок. Это в конечном итоге приводит к тому, что AssemblyLoader ищет неправильное место для встроенного ресурса.

Когда вы повторяете эксперимент с С#, он включает имена подпапок.

EDIT - Изменено, чтобы отразить, что для VB ресурс, на котором он должен находиться на корневом уровне.

То, с чем мне удалось, заключалось в том, чтобы встроенный ресурс был в той же папке, что и код, который его использует (лучше для управления версиями). Затем я LIED в атрибуте И вызов Page.ClientScript.GetWebResourceUrl для учетной записи компилятора VB, утверждая, что встроенный ресурс не имеет путей.


Это немного сжимается на соломинках, но может ли быть так, что ваш asp.net не настроен правильно обработать webresource.axd? Если что-то пошло не так, возможно, тег обработчика отсутствует на машине web.config?

Тэг обработчиков C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config должен иметь запись webresource.axd следующим образом:

<httphandlers> </httphandlers>

Также дважды проверьте, нет ли записи обработчика в проекте web.config, который мог бы переопределить параметр из машины web.config.


этому блогу уже два года... но я потратил несколько дней на попытку заставить это работать. Попытка получить встроенный js файл, чтобы дать мне строку запроса WebResource.asx, которая будет работать. Последняя часть, которая, кажется, затушевывает здесь, состоит в том, что файл, который вы встроили, должен находиться в той же структуре физического каталога, что и код управления, за которым вы вызываете GetWebResourceUrl(). Если вы поместили встроенный файл в папку под названием "scripts", затем вызвали GetWebResourceUrl() с главной страницы, которая НЕ найдена в "сценариях", возвращенный ResourceURL указывает на неправильное местоположение... таким образом ВСЕГДА возвращает 404.

если вы используете MasterPage как тип для первого параметра, он никогда не будет работать. GetWebResourceUrl(typeof(MasterPage),... Я думаю, что реальный ключ здесь заключается в том, что вам нужно отказаться от встроенного ресурса в том же месте, которое вы собираетесь использовать в качестве типа для первого параметра ResourceURL. После 3 дней борьбы с этой штукой он наконец нашел свой ресурс.


Только эта проблема и решила ее на основе ответа meandmycode; однако, возможно, требуется более подробное объяснение.

Когда вы регистрируете блок script с помощью метода ScriptManager.RegisterClientScriptInclude, параметр "type" должен быть класса внутри того же проекта, что и .js script. Если у вас нет класса, связанного с блоком script, вам просто нужно будет выбрать другой класс.


У меня была аналогичная проблема, и в моем случае это было вызвано тем, что параметр Page.ClientScript.GetWebResourceUrl resourceName чувствителен к регистру.


Атрибуты

[assembly:] должны находиться в файле Properties\************.cs. Несмотря на то, что проект скомпилирован, когда атрибуты сборки находятся в пользовательском файле управления, они не отображаются в WebResource.axd.


Как уже упоминалось в meandmycode, тип, переданный в GetWebResourceUrl, является ключом

Мне не нравился тип передачи, где это не имеет большого значения, я решил его с помощью такого вспомогательного метода

static public string GetEmbeddedResourceLink(Page page, string assemblyName, string resource) { var assembly = Assembly.Load(assemblyName); var types = assembly.GetTypes(); if (types.Length == 0) { throw new ArgumentException("assembly does not contain any type"); } return page.ClientScript.GetWebResourceUrl(types[0], resource);
}


Ответ на ваш вопрос полностью зависит от того, где у вас есть этот файл в вашем фактическом проекте, и что такое пространство имен по умолчанию. Как отметил Крис, путь, который вы предоставляете методам регистрации script, должен иметь правильный путь для поиска встроенного ресурса. Вы не просто согласуете строку, указанную в ************. Строка должна быть правильным путем к ресурсу.

< пространство имен проектов по умолчанию> /< любые подпапки у вас есть файл в> /


Поверните это:

Page.ClientScript.RegisterClientScriptInclude("NavigationScript"...

в это:

Page.ClientScript.RegisterClientScriptInclude("CompanyProduct.Library.navigation.js"...


Является ли ресурс, который вы добавляете в другой сборке, к коду, который используется для создания тега script? Если это так, я думаю, что this.GetType() вернет ссылку на тип в неправильной сборке, поэтому код веб-ресурса не будет иметь правильную сборку для загрузки ресурса.

Я не знаю точно, что это будет проблемой, но мне кажется, что код, который сгенерировал имя, должен был знать, какая сборка была включена или он не сможет сопоставить это когда он получил запрос от браузера.


У меня была аналогичная ситуация, и примерно через 4 часа исследования и тестирования я получил окончательное решение: По умолчанию пространство имен должно совпадать с именем сборки. (Можно использовать Reflector или использовать приведенный ниже фрагмент кода, чтобы получить имена встроенных ресурсов.

string[] embeddedResNames = Assembly.LoadFile("YourDll.dll").GetManifestResourceNames()

licensed under cc by-sa 3.0 with attribution.