将javascript文件标记为“嵌入式资源”
将WebResource属性添加到我的AssemblyInfo类中
现在我正在尝试将嵌入式javascript输出到我的母版页。我所得到的只是来自网络资源网址的“未找到网络资源”。
项目大会名称:
CompanyProduct
项目默认命名空间:
Company.Product.Web
Javascript文件位于:
库/ navigation.js
集信息:
[assembly: WebResource("CompanyProduct.Library.navigation.js", "text/javascript")]
母版页中的代码:
Page.ClientScript.RegisterClientScriptInclude("NavigationScript", Page.ClientScript.GetWebResourceUrl(this.GetType(), "CompanyProduct.Library.navigation.js"));
答案 0 :(得分:14)
而不是this.GetType()
,从包含资源的程序集中获取一个类型.. ie:
typeof(Company.Product.Web.Library.Class1)
这有用吗?
答案 1 :(得分:4)
今天来到同一个问题。问题似乎是AssemblyResourceLoader使用包含提供给GetWebResourceUrl
方法(第一个参数)的类型的程序集,在您的情况下,它是为主页(.master)动态创建的程序集,并且不包含您的资源寻找。我假设您的资源文件包含在与基本母版页(.master.cs文件)相同的程序集中,然后您可以使用typeof
来获取Type实例
Page.ClientScript.RegisterClientScriptInclude(
"NavigationScript",
Page.ClientScript.GetWebResourceUrl(
typeof(MyMasterPage),
"CompanyProduct.Library.navigation.js"));
其中MyMasterPage是主页的名称
看起来也可以使用在嵌入资源的同一程序集中声明的任何其他类型。
答案 2 :(得分:3)
我认为您希望完整路径基于命名空间,而不是程序集;因此,只要您拥有“CompanyProduct.Library.navigation.js”,请将其替换为“Company.Product.Web.Library.navigation.js”。此外,还有一个方法Page.ClientScript.RegisterClientScriptResource()可以在一个方法中执行您需要的操作(而不是使用RegisterClientScriptInclude(GetWebResourceUrl())。
答案 3 :(得分:1)
这有点紧贴稻草,但可能是你的asp.net没有设置正确处理webresource.axd吗?如果出现问题,可能是机器的web.config中缺少处理程序标记?
C:\ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG \ web.config的http处理程序标记应该有一个webresource.axd条目,如下所示:
<httpHandlers>
<add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True"/>
</httpHandlers>
同样仔细检查项目的web.config中是否有任何处理程序条目可以从机器的web.config覆盖该设置。
答案 4 :(得分:1)
这个博客现在已经有两年了......但是我花了几天时间试图让它发挥作用。试图获取一个嵌入式js文件实际上给我一个可以工作的WebResource.asx查询字符串。似乎在这里隐藏的最后一块是你嵌入的文件与你从中调用GetWebResourceUrl()
的控件代码隐藏在同一物理目录结构中。如果您已将嵌入文件放在名为“scripts”的文件夹中,然后从主页面调用GetWebResourceUrl()
,而在“脚本”中找不到,则返回的ResourceURL将指向错误的位置...因此总是如此返回404。
如果您使用MasterPage作为第一个参数的类型,那么它将永远不会工作。 GetWebResourceUrl(typeof(MasterPage)
,...我想这里真正的关键是你必须将嵌入式资源放到你将用作ResourceURL第一个参数类型的相同位置。经过3天的摔跤,终于找到了我的资源。
答案 5 :(得分:1)
对于碰巧使用VB的人来说 - VB编译器和C#编译器之间的行为存在差异。
在VB中,嵌入式资源必须位于项目的根级别。当我用ILDASM查看生成的程序集时,我发现嵌入资源的名称NEVER包含任何子文件夹的名称。这最终导致AssemblyLoader查找嵌入式资源的错误位置。
当您使用C#重复实验时,它会包含子文件夹的名称。
编辑 - 更改为反映VB对于它必须位于根级别的资源。
我成功的是将嵌入式资源放在与使用它的代码相同的文件夹中(更好的源代码控制)。然后我在属性和Page.ClientScript.GetWebResourceUrl中调用LIED,以便说明VB编译器声称嵌入式资源没有路径。
答案 6 :(得分:1)
刚出现这个问题并根据meandmycode的反应解决了这个问题;但是,可能需要更详细的解释。
使用ScriptManager.RegisterClientScriptInclude
方法注册脚本块时,“type”参数必须是与.js脚本在同一项目中的类。如果没有与脚本块关联的类,则只需要选择另一个类。
答案 7 :(得分:1)
我遇到了类似的问题,在我看来,这是因为Page.ClientScript.GetWebResourceUrl
resourceName 参数区分大小写这一事实。
答案 8 :(得分:0)
您的问题的答案完全取决于您在实际项目中拥有此文件的位置以及默认命名空间的位置。正如Chris所提到的,您为注册脚本的方法提供的路径需要正确的路径来定位嵌入式资源。您不只是匹配您在AssemblyInfo中指定的字符串。字符串必须是资源的正确路径。
&LT;默认项目名称空间&gt; /&lt;您拥有&gt; /&lt;中文件的所有子文件夹文件名&gt;
答案 9 :(得分:0)
转动这个;
Page.ClientScript.RegisterClientScriptInclude("NavigationScript"...
进入这个;
Page.ClientScript.RegisterClientScriptInclude("CompanyProduct.Library.navigation.js"...
答案 10 :(得分:0)
您在不同程序集中添加的资源是否是您用于生成脚本标记的代码?如果是这种情况,我认为this.GetType()将返回对错误程序集中的类型的引用,因此Web资源代码将没有正确的程序集来加载资源。
我不确定这会是一个问题,但在我看来,生成名称的代码需要知道资源所在的程序集,或者它无法映射回那个从浏览器收到请求时的汇编。
答案 11 :(得分:0)
我有类似的情况,经过大约4个小时的研究和测试后,我得到了最终解决方案:默认命名空间必须与程序集名称相同。
(可以使用Reflector或使用下面的代码片段来获取嵌入资源的名称。
string[] embeddedResNames = Assembly.LoadFile("YourDll.dll").GetManifestResourceNames()
答案 12 :(得分:0)
正如meandmycode已经提到的,传递给GetWebResourceUrl
的类型是关键
我并不喜欢传递类型并不重要,我用这种辅助方法解决了它
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);
}
答案 13 :(得分:0)
[assembly:]属性必须位于Properties \ AssemblyInfo.cs文件中。即使在汇编属性位于自定义控件文件中时编译项目,WebResource.axd也看不到它们。
答案 14 :(得分:0)
在这里尝试了大多数解决方案之后,我发现this other StackOverflow answer起作用了。
在DLL上标记的时间必须在当前时间之后,否则WebResource.axd
将不会为其提供资源。
此机制似乎完全不了解时区差异。如果您的CI服务器位于比目标Web服务器更东的时区,则两个时区之间的时差会使资源不可用,直到Web服务器时间达到DLL上的时间为止。解决方案是使用构建脚本中的Set-TimeZone确保CI代理的时区设置为与目标服务器相同(或比目标服务器更西)。
当然,理想的解决方案是将所有服务器设置为UTC,但并非所有应用程序都被编码为与时区无关。