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

assemblies

Question

Obtengo un error de estado HTTP 404 (no encontrado) en una llamada WebResource.axd específica dentro de una aplicación web ASP.NET 3.5 (AJAX). Supongo que el error se produce porque falta un ensamblaje referenciado específico en la carpeta bin / GAC. Pero no sé cuál, 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 de la cadena de consulta "d" cifrado de la consulta, como:

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

¿Qué ensamblado debería crear el contenido y posiblemente falte?

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

Answer 1

¿Le faltan referencias a su proyecto?

¿Hay alguna referencia establecida en CopyLocal = False (común con Infragistics o referencias GAC) que no llega al destino?

Una utilidad como reflector o walker de dependencias le dirá si su ensamblaje principal no tiene dependencias que no sean inmediatamente obvias.

¿El controlador Application_Error en global.asax tiene una captura que está produciendo cualquier información de error (FileNotFoundExceptions)?

¿Estableció los errores personalizados en "solo a control remoto" y navega por el sitio desde la máquina local?

Answer 2

Acabo de pasar horas en un problema similar. Debido al excelente artículo señalado por Diadistis, pude descifrar la url de WebResource y descubrir que mi WebResource se tradujo en un puntero de ensamblaje incorrecto, reconocible por la basura que está frente al nombre de tu recurso. Después de muchas dificultades descubrí que esto era porque estaba usando el Page.ClientScript.GetWebResourceUrl en una clase derivada de otra clase que residía fuera del ensamblado en el que estaba mi recurso. Lo confuso fue que mi clase estaba en el mismo ensamblado, aunque la clase que se deriva de NO. El parámetro this.GetType () que muchos artículos dicen que es obligatorio, resultó no ser tan necesario en mi situación. En realidad, necesitaba ser reemplazado con un typeof () ¡y funcionó! Espero que esto pueda evitar que otros sufran el mismo dolor de cabeza que recibí de este insecto.

Answer 3

En mi caso, la fuente del error 404 fue que la fecha y la hora de la máquina que ejecutaba IIS eran incorrectas (del pasado).

Answer 4

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

Asp.net utiliza WebResourceAttribute, que debe proporcionar la ruta al recurso.

El archivo de recursos debe agregarse como un recurso incrustado al proyecto y la ruta a él sería el espacio de nombre completo más el nombre del archivo.

Entonces, tiene el siguiente recurso de 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 la url WebResource.axd. 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- descifrar-la-url-y-obtener-el-nombre-de-recursos.aspx

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