asp.net - Infierno de WebResource-no se puede encontrar el recurso
embedded-resource (14)
Creo que desea que las rutas completas se basen en el espacio de nombres, no en el conjunto; Entonces, en cualquier lugar donde tenga "CompanyProduct.Library.navigation.js", reemplácelo por "Company.Product.Web.Library.navigation.js". Además, hay un método Page.ClientScript.RegisterClientScriptResource () que hace lo que necesita en un método (en lugar de usar RegisterClientScriptInclude (GetWebResourceUrl ()).
Marcó un archivo javascript como "recurso incrustado"
Se agregó el atributo WebResource a mi clase AssemblyInfo
Ahora estoy tratando de generar el javascript incrustado en mi página maestra. Todo lo que obtengo es un "Recurso web no encontrado" de la url de recursos web.
Nombre del ensamblado del proyecto:
CompanyProduct
Espacio de nombre predeterminado del proyecto:
Company.Product.Web
Archivo Javascript ubicado:
Biblioteca / navigation.js
AssemblyInfo:
[assembly: WebResource("CompanyProduct.Library.navigation.js", "text/javascript")]
Código en la página maestra:
Page.ClientScript.RegisterClientScriptInclude("NavigationScript", Page.ClientScript.GetWebResourceUrl(this.GetType(), "CompanyProduct.Library.navigation.js"));
Error del servidor en la aplicación ''/''.
El recurso no puede ser encontrado.
Descripción: HTTP 404. El recurso que está buscando (o una de sus dependencias) podría haberse eliminado, haber cambiado su nombre o no estar disponible temporalmente. Revise la siguiente URL y asegúrese de que esté escrita correctamente.URL solicitada: /WebResource.axd
Información de la versión: Microsoft .NET Framework Version: 2.0.50727.1433; Versión ASP.NET: 2.0.50727.1433
La respuesta a su pregunta depende completamente de dónde tiene este archivo en su proyecto real y cuál es el espacio de nombre predeterminado. Como mencionó Chris, la ruta que proporcione a los métodos que registran el script necesita la ruta correcta para ubicar el recurso incrustado. No solo coincide con la cadena que especifica en su AssemblyInfo. La cadena debe ser la ruta correcta al recurso.
<espacio de nombres de proyecto predeterminado> / <cualquier subcarpeta en la que tenga el archivo> / <nombre de archivo>
Convierta este;
Page.ClientScript.RegisterClientScriptInclude("NavigationScript"...
dentro de esto;
Page.ClientScript.RegisterClientScriptInclude("CompanyProduct.Library.navigation.js"...
Esto se aferra un poco a las pajas, pero ¿podría ser que su asp.net no esté configurado para procesar webresource.axd correctamente? Si algo ha fallado, tal vez la etiqueta del controlador no se encuentre en la web.config de la máquina?
La etiqueta de controladores http de C: / Windows / Microsoft.NET / Framework / v2.0.50727 / CONFIG / web.config debe tener una entrada webresource.axd como esta:
<httpHandlers>
<add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True"/>
</httpHandlers>
Además, compruebe que no haya ninguna entrada de controlador en el web.config del proyecto que pueda anular la configuración desde la web.config de la máquina.
¿Está el recurso que está agregando en un ensamblaje diferente al código que está utilizando para generar la etiqueta de secuencia de comandos? Si ese es el caso, creo que esto. GetType () devolverá una referencia a un tipo en el ensamblaje incorrecto para que el código de recursos web no tenga el ensamblaje correcto para cargar el recurso.
No estoy seguro de que esto sea un problema, pero me parece que el código que generó el nombre necesitaría saber en qué ensamblaje estaba el recurso o no podría volver a mapearlo cuando recibió la solicitud del navegador.
Llegó al mismo problema hoy. El problema parece ser que AssemblyResourceLoader usa el ensamblado que contiene el tipo proporcionado al método GetWebResourceUrl (primer parámetro) que en su caso es un ensamblaje creado dinámicamente para la página maestra (.master) y no contiene el recurso que está buscando. Supongo que su archivo de recursos está incluido en el mismo ensamblaje que su página maestra base (archivo .master.cs), entonces podría usar typeof para obtener la instancia de Tipo
Page.ClientScript.RegisterClientScriptInclude(
"NavigationScript",
Page.ClientScript.GetWebResourceUrl(
typeof(MyMasterPage),
"CompanyProduct.Library.navigation.js"));
donde MyMasterPage es el nombre de su página maestra
Parece que también es posible usar cualquier otro tipo declarado en el mismo ensamblaje donde está incrustado el recurso.
En lugar de this.GetType() , obtenga un tipo del ensamblado que contiene el recurso ... es decir:
typeof(Company.Product.Web.Library.Class1)
¿Eso funciona?
Tuve una situación similar, y después de aproximadamente 4 horas de investigación y prueba obtuve la solución final: el espacio de nombre predeterminado debe ser el mismo que el nombre del ensamblado .
(Se podría usar Reflector o usar el siguiente fragmento de código para obtener los nombres de los recursos incrustados.
string[] embeddedResNames = Assembly.LoadFile("YourDll.dll").GetManifestResourceNames()
Como meandmycode ya se mencionó, el tipo pasado a GetWebResourceUrl es la clave
No me gustaba pasar el tipo donde realmente no importa, lo resolví con este tipo de método de ayuda
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);
}
Para cualquiera que esté usando VB, existe una diferencia de comportamiento entre el compilador de VB y el compilador de C #.
En VB, el recurso incrustado TIENE que estar en el nivel raíz de su proyecto. Cuando miré el ensamblado generado con ILDASM, encontré que el nombre del recurso incrustado NUNCA incluye los nombres de las subcarpetas. Eventualmente, esto hace que AssemblyLoader busque en el lugar incorrecto el recurso incrustado.
Cuando repites el experimento con C #, INCLUYE los nombres de las subcarpetas.
EDITAR - Modificado para reflejar que para VB el recurso TIENE que estar en el nivel raíz.
Lo que logré fue tener el recurso incrustado en la misma carpeta que el código que lo usa (mejor para el control de fuente). Luego MINTIÉ en el Atributo Y la llamada de la página.ClientScript.GetWebResourceUrl a la cuenta para el compilador de VB que afirma que el recurso incrustado no tiene rutas.
este blog tiene dos años ahora ... pero pasé días tratando de hacer que esto funcione. Tratando de obtener un archivo js incrustado para darme realmente una cadena de consulta WebResource.asx que funcionaría. La última pieza que parece ser minimizada aquí es que el archivo que ha incrustado TIENE que estar en la misma estructura de directorios físicos que el código de control detrás del que está llamando GetWebResourceUrl() . Si ha colocado el archivo incrustado en una carpeta llamada "scripts", luego se llama GetWebResourceUrl() desde la página maestra que NO se encuentra en "scripts", la ResourceURL devuelta apuntará a la ubicación incorrecta ... lo que SIEMPRE devolverá un 404.
si está utilizando la página maestra como el tipo para el primer param, entonces nunca funcionará. GetWebResourceUrl(typeof(MasterPage) , ... Supongo que la verdadera clave aquí es que debe soltar el recurso incrustado en la misma ubicación que va a usar como tipo para el primer parámetro de ResourceURL. Después de 3 días de luchando con esto, finalmente encontró mi Recurso.
Los atributos [assembly:] deben estar en el archivo Properties / AssemblyInfo.cs. Aunque el proyecto se compila cuando los atributos de ensamblaje están en el archivo de control personalizado, no son visibles para WebResource.axd.
Acabo de tener este problema y lo resolvió en función de la respuesta de meandmycode; sin embargo, tal vez se necesite una explicación más detallada.
Cuando registra el bloque de scripts utilizando el método ScriptManager.RegisterClientScriptInclude , el parámetro "tipo" debe ser de una clase dentro del mismo proyecto que el script .js. Si no tiene ninguna clase asociada con el bloque de script, tendrá que elegir otra clase.
Tuve un problema similar y, en mi caso, fue causado por el hecho de que el parámetro Page.ClientScript.GetWebResourceUrl resourceName Page.ClientScript.GetWebResourceUrl mayúsculas y minúsculas .