WebResource.axd 链接访问的嵌入式资源在生产环境中不起作用
好吧，这让我难住了。
我在 VB.NET .NET 4 项目中定义了几个服务器控件（我们称之为 WebControls），以便与解决方案中的其他项目共享。 WebControls 使用嵌入式资源（图像），因此我不必记住在引用控件的每个项目中包含图像。我使用 Page.ClientScript.GetWebResourceUrl 在服务器控件中设置图像 ImageUrl 属性。
这一切在我的应用程序 X 中运行良好，该应用程序使用我的开发服务器上的 WebControls 控件。但是，当我将其投入生产时，表示为嵌入式资源的图像不会显示。
我的生产服务器运行 IIS 7.0。我知道禁用压缩不会影响任何内容，并且 Web 资源 .axd 文件存在适当的 IIS 处理程序。
更奇怪的是，我在同一个生产服务器上有这个应用程序的副本（当然名称不同），并且在这些服务器中一切正常，但在 X 中则不然。应用程序池使用集成的 .NET 4，并且无法在经典模式下工作。
有什么建议吗？
Ok, this has me stumped.
I have several server controls defined in a VB.NET .NET 4 project, lets call it WebControls, to be shared with other projects in the solution. WebControls uses embedded resources (images) so that I don't have to remember to include images in each project that reference the controls. I use Page.ClientScript.GetWebResourceUrl to set image ImageUrl attributes in the server controls.
This all works fine in my application X that uses the controls from WebControls on my dev server. However, when I push this to production, the images represented as embedded resources do not show up.
My production server runs IIS 7.0. I know that disabling compression does not affect anything and that the proper IIS handlers are present for web resource .axd files.
What is even stranger is that I have copies of this application (named differently of course) on that same production server and everything works fine in those, but not in X. The application pool uses .NET 4 integrated and will not work on classic mode.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
想通了这一点。很奇怪。我在调试模式下重建了 WebControls 类和其他应用程序，并将这些 .dll 推送到我的生产服务器，一切正常。然后，我在发布模式下重建并再次将 .dll 推入生产环境，替换调试 .dll，并且再次一切正常。当我清理并重建要发布的应用程序时，VS 2010 似乎没有正确清除 dll 的问题。
Figured this out. Very strange. I rebuilt my WebControls class and my other applications in debug mode and pushed those .dlls to my production server and everything worked fine. Then, I rebuilt in release mode and pushed the .dlls to production again, replacing the debug .dlls, and again all worked fine. Seems to have been an issue with VS 2010 not clearing out the dlls correctly when I cleaned and rebuilt my applications for release.