ASP.NET: ошибка 404 вызова WebResource.axd: как узнать, какая сборка / ресурс отсутствует или ответственна - PullRequest
24 голосов
/ 12 января 2009

Я получаю 404 ошибку состояния HTTP (не найдена) на конкретном вызове WebResource.axd внутри веб-приложения ASP.NET 3.5 (AJAX). Я предполагаю, что ошибка генерируется, потому что в папке bin / GAC отсутствует конкретная ссылочная сборка. Но я не знаю, какая, поскольку страница, запрашивающая ресурс, очень сложна (я использую сторонние элементы управления и ASP.NET Ajax.)

Можно ли узнать по зашифрованному параметру строки запроса d, например:

.../WebResource.axd?d=...

какая сборка должна создавать контент и, возможно, отсутствует?

Примечание: Существуют другие вызовы WebRequest.axd, которые выполняются с успехом.

Ответы [ 4 ]

31 голосов
/ 12 января 2009

Одна из причин этой проблемы заключается в том, что зарегистрированный путь к встроенному ресурсу неверен или ресурса там нет. Убедитесь, что файл ресурса добавлен как Embedded Resource .

Asp.net использует WebResourceAttribute , который необходимо указать путь к ресурсу.

Файл ресурса необходимо добавить в проект как встроенный ресурс, а путь к нему будет полным пространством имен плюс имя файла.

Таким образом, у вас есть следующий ресурс проекта "my.js" в проекте "MyAssembly", путь к файлу которого будет "MyAssembly.my.js".

Чтобы проверить, какой файл не находит обработчик веб-ресурса, вы можете расшифровать хеш-код, указанный в URL-адресе WebResource.axd. Пожалуйста, посмотрите пример ниже и как это сделать.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Web;

namespace WebApplication1
{
    public partial class WebForm1 : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            byte[] encryptedData = HttpServerUtility.UrlTokenDecode("encoded hash value");

            Type machineKeySection = typeof(System.Web.Configuration.MachineKeySection);
            Type[] paramTypes = new Type[] { typeof(bool), typeof(byte[]), typeof(byte[]), typeof(int), typeof(int) };
            MethodInfo encryptOrDecryptData = machineKeySection.GetMethod("EncryptOrDecryptData", BindingFlags.Static | BindingFlags.NonPublic, null, paramTypes, null);

            try
            {
                byte[] decryptedData = (byte[])encryptOrDecryptData.Invoke(null, new object[] { false, encryptedData, null, 0, encryptedData.Length });
                string decrypted = System.Text.Encoding.UTF8.GetString(decryptedData);

                decryptedLabel.Text = decrypted;
            }
            catch (TargetInvocationException)
            {
                decryptedLabel.Text = "Error decrypting data. Are you running your page on the same server and inside the same application as the web resource URL that was generated?";
            } 
        }
    }
}

Пример оригинального кода от Telerik UI для ASP.NET AJAX Team Link: http://blogs.telerik.com/aspnet-ajax/posts/07-03-27/debugging-asp-net-2-0-web-resources-decrypting-the-url-and-getting-the-resource-name.aspx

Это должно вернуть URL-путь, который, по мнению aspt.net, находится на встроенном ресурсе.

11 голосов
/ 12 декабря 2009

Я просто часами занимался аналогичной проблемой. Благодаря замечательной статье, на которую указал Diadistis, я смог расшифровать URL-адрес WebResource и выяснить, что мой WebResource был преобразован в неправильный указатель сборки, который распознается мусором перед именем вашего ресурса. После многих трудностей я обнаружил, что это потому, что я использовал Page.ClientScript.GetWebResourceUrl в классе, производном от другого класса, который находился вне сборки, в которой находился мой ресурс. Смущает то, что мой класс был в той же сборке, хотя класс, производный от был НЕТ. Параметр this.GetType () во многих статьях является обязательным, а в моей ситуации это вовсе не является обязательным условием. На самом деле, его нужно было заменить на typeof (), и это сработало! Надеюсь, что это может помешать другим получить такую ​​же головную боль, какую я получил от этого педераста.

10 голосов
/ 09 марта 2012

В моем случае источником ошибки 404 было то, что дата и время машины, на которой работал IIS, были неправильными (из прошлого).

2 голосов
/ 12 января 2009

В вашем проекте отсутствуют какие-либо ссылки?

Есть ли какие-либо ссылки, установленные на CopyLocal = False (общие с ссылками Infragistics или GAC), которые не попадают в пункт назначения?

Утилита, такая как отражатель или обходчик зависимостей, сообщит вам, если в вашей основной сборке отсутствуют какие-либо зависимости, которые не сразу очевидны.

Имеет ли обработчик Application_Error в global.asax перехват, который генерирует какую-либо информацию об ошибке (FileNotFoundExceptions)?

Вы установили пользовательские ошибки на "только удаленное" и просматривали сайт с локального компьютера?

...