Silverlight 应用程序在尝试使用 RIA 服务时出现 4004 错误
我编写了一个 Silverlight 应用程序,它基本上是一个帐户注册表单。我已经能够成功地将其部署到运行 Windows Server 2008/IIS7 的生产服务器之一。虽然这需要一些时间,但我能够相当轻松地解决并解决出现的问题。现在我正在尝试在我们的主生产服务器上部署该应用程序。该服务器运行的是 Windows 2003/IIS6,这就是我遇到一些问题的地方。
我已经解决了大部分问题,现在 silverlight 应用程序将加载,我可以在表单消失之前看到它几秒钟。我相信在此期间它正在尝试使用 RIA 服务从数据库加载数据。
在 IE 中,我收到以下错误:
Webpage error details
Message: Unhandled Error in Silverlight Application
Code: 4004
Category: ManagedRuntimeError
Message: System.Windows.Markup.XamlParseException:
System.Windows.Markup.XamlParseException:
System.Windows.Markup.XamlParseException:
Cannot find a Resource with the Name/Key ApplicationResources [Line: 6 Position: 9]
我相信这一定是 IIS6 中的配置问题,因为该应用程序在 IIS7 上运行良好,但我不知道要尝试什么。我花了几个小时试图找到这个特定问题的解决方案,虽然其他人提到了解决这个问题,但答案本质上总是不具体。
这就是我到目前为止所做的:
- 为 .NET 4 添加新应用程序池。
- 在 ASP.NET 选项卡上将网站设置为使用 .NET 4(执行 iisreset 时几乎心力衰竭)。
- 添加了 Silverlight .xaml、.xap 等的 MIME 类型。
- 未选中集成 Windows 身份验证(选中时出现错误)。
- 授予脚本和可执行文件执行权限。
- 回收了应用程序池。
我看到建议但没有尝试过的一件事是 iisreset,虽然我不完全相信这样做可以解决问题,但我们已安排今晚完成此操作(如果在那之前我找不到解决方案)。
所以基本上我想知道是否有人见过这个问题并知道如何解决它?
更新 1:我们昨晚尝试了 iisreset,正如我所料,这没有解决问题。
I have written a Silverlight application that is basically an account registration form. I have been able to successfully deploy this to one of our production servers running windows server 2008/IIS7. While this took some time to do, I was able to work through and solve the issues that came up fairly easily. Now I am trying to deploy the application on our main production server. This server is running windows 2003/IIS6 and this is where I have hit some problems.
I have solved most of the issues and now the silverlight application will load and I can see the form for a few seconds before it disappears. I believe during this time it is trying to load data from the database using the RIA services.
In IE I get the following error:
Webpage error details
Message: Unhandled Error in Silverlight Application
Code: 4004
Category: ManagedRuntimeError
Message: System.Windows.Markup.XamlParseException:
System.Windows.Markup.XamlParseException:
System.Windows.Markup.XamlParseException:
Cannot find a Resource with the Name/Key ApplicationResources [Line: 6 Position: 9]
I believe it must be a configuration issue in IIS6 because the app works fine on IIS7 but I am drawing a blank as to what to try. I have spent hours trying to find a solution to this particular problem and while others have mentioned getting this problem the answers always tend to be non-specific in nature.
This is what I have done so far:
- Added New Application Pool for .NET 4.
- Set the website to use .NET 4 on the ASP.NET tab (nearly had heart failure when this did an iisreset).
- Added the MIME types for Silverlight .xaml, .xap, etc.
- Unchecked Integrated Windows Authentication (was giving an error when checked).
- Give Execute permissions to Scripts and Executables.
- Recycled the application pool.
The one thing I have seen suggested but have not tried is an iisreset, and while I am not entirely convinced that doing this would solve the problem, we have scheduled this to be done tonight (if I cannot find a solution before then).
So basically I am wondering if anyone out there has seen this problem and knows how to solve it?
UPDATE 1: We tried an iisreset last night and as I expected this did not solve the problem.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好吧,我已经解决了问题。正如建议的那样,我对应用程序进行了 WCF 跟踪。这立即突出了真正问题,即“对象的 SELECT 权限被拒绝...”。一旦我解决了这个问题,应用程序就会按我的预期工作。事实证明,我的一位同事已经在我们的另一台服务器(运行 IIS7)上进行了此权限更改,因此这就是它在那里工作的原因(这很糟糕 - 我知道)。
此外,我在客户端收到的 JavaScript 错误(如问题所示)与根本问题无关,并引导我真正沿着花园小路走下去,这也没有帮助。
Okay I have solved the problem. As suggested I did a WCF trace on the application. This highlighted the REAL problem straight away, which was 'The SELECT permission was denied on the object...'. Once I fixed this the application works as I expected. It turns out that a colleague of mine had already made this permission change on our other server (running IIS7) so that was why it worked there (this is bad - I know).
Also it didn't help that the javascript error I was receiving on the client side (shown in the question) had nothing to do with the underlying issue and led me well and truly up the garden path.