Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

<httpHandlers>
    <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True"/>
</httpHandlers>

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

в это:

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

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

Как уже упоминалось в 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);
}

Ответ 14

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