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

Question

Recibo un error de estado HTTP 404 (no encontrado) en una llamada específica de WebResource.axd dentro de una aplicación web ASP.NET 3.5 (AJAX). Supongo que se produce el error porque falta un ensamblado 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 de la " d " encriptada parámetro de cadena de consulta de la consulta, como:

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

¿qué ensamblaje debería crear el contenido y posiblemente no se encuentre?

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

Answer 1

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

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

El archivo de recursos debe agregarse como un recurso incorporado al proyecto y la ruta al mismo sería el espacio de nombres 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 controlador de recursos web, puede descifrar el código hash proporcionado en la URL de WebResource.axd. Consulte el siguiente ejemplo 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 en la que aspt.net cree que se encuentra el recurso incrustado.

Answer 2

Acabo de pasar horas en un problema 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 ensamblaje incorrecto, reconocible por la basura frente a su nombre de recurso. Después de muchas dificultades descubrí que esto se debía a que estaba usando 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 ensamblaje, aunque la clase derivada de NO. El parámetro this.GetType () que muchos artículos establecen es un deber, resultó no ser tan obligatorio en mi situación. En realidad, necesitaba ser reemplazado por un typeof () y funcionó. Espero que esto evite que otros tengan el mismo dolor de cabeza que el que tuve con este insector.

Answer 3

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

Answer 4

¿Le faltan referencias a su proyecto?

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

Una utilidad como el reflector o el caminante de dependencias le dirá si a su ensamblaje principal le faltan dependencias que no sean obvias de inmediato.

¿El Application_Error manejador en global.asax tiene un problema que produce información de error (FileNotFoundExceptions)?

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