ASP.NET: WebResource.axd call 404 error: ¿cómo saber qué ensamblado/recurso falta o es el responsable?


Obtengo un error de estado HTTP 404 (no encontrado) en un recurso web específico.axd llamada dentro de un ASP.NET 3.5 (AJAX) aplicación web. Supongo que el error se produce porque falta un ensamblado de referencia específico en la carpeta bin/GAC. Pero no se cual, ya que la página que solicita el recurso es muy compleja (estoy usando controles de terceros y ASP.NET Ajax.)

¿Es posible saber a partir del parámetro querystring "d" cifrado de la consulta, como:

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

¿Qué ensamblado debe crear el contenido y posiblemente falta?

Nota: Hay otros WebRequest.llamadas axd que se ejecutan con éxito.

Author: Kiquenet, 2009-01-12

4 answers

Una de las razones de este problema es que la ruta del recurso incrustado registrada es incorrecta o el recurso no está allí. Asegúrese de que el archivo de recursos se agrega como un Recurso incrustado .

Asp.net utiliza el WebResourceAttribute que debe dar la ruta al recurso.

El archivo de recursos debe agregarse como un Recurso Incrustado al proyecto y la ruta al mismo sería el espacio de nombres completo más el nombre del archivo.

Así que tienes lo siguiente recurso del proyecto " my.js " en el proyecto "MyAssembly" la ruta del recurso sería "MyAssembly.my.js".

Para verificar qué archivo no encuentra el manejador de recursos web, puede descifrar el código hash proporcionado en el WebResource.axd url. Por favor, vea el ejemplo a continuación y cómo hacerlo.

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?";
            } 
        }
    }
}

Ejemplo de código original de Telerik UI para 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

Esto debería devolver la ruta URL que aspt.net cree que el recurso incrustado está en.

 31
Author: Diadistis,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-06-03 10:00:26

Acabo de pasar horas en un tema similar. Debido al gran artículo señalado por Diadistis, pude descifrar la url de WebResource y descubrir que mi WebResource se tradujo en un puntero de ensamblado incorrecto, reconocible por la basura frente al nombre de su recurso. Después de muchas luchas descubrí que esto era porque estaba usando la Página.ClientScript.GetWebResourceUrl en una clase derivada de otra clase que residía fuera del ensamblado en el que estaba mi recurso. Cosa confusa era que mi clase ESTABA en la misma asamblea, aunque la clase derivada de NO lo estaba. El esto.GetType () parámetro muchos artículos estado es una necesidad, resultó no ser tanto de una necesidad en absoluto en mi situación. En realidad, necesitaba ser reemplazado con un typeof() y funcionó! Espero que esto pueda evitar que otros tengan el mismo dolor de cabeza que yo tuve de este cabrón.

 11
Author: Koen Zomers,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-12-11 21:51:26

En mi caso, la fuente del error 404 fue que la fecha y hora de la máquina que ejecuta IIS estaban equivocadas (del pasado).

 10
Author: gogowitsch,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-03-09 11:26:14

¿Le falta alguna referencia a su proyecto?

¿Hay alguna referencia establecida en CopyLocal=False (común con Infragistics o GAC'ed refs) que no llegue al destino?

Una utilidad como reflector o dependency walker le dirá si a su ensamblaje principal le falta alguna dependencia que no sea obvia inmediatamente.

Hace el manejador Application_Error en global.asax tiene una captura que está produciendo cualquier información de error (FileNotFoundExceptions)?

¿Ha establecido errores personalizados en 'solo remoto' y navegar por el sitio desde la máquina local?

 2
Author: StingyJack,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-01-12 12:52:12