在已部署的3层LightSwitch 应用程序中诊断问题（艾瑞克·埃尔哈特）

在已部署的3层LightSwitch 应用程序中诊断问题（艾瑞克·埃尔哈特）

时常LightSwitch 应用程序在开发人员的机器上运行得很完美，但是当部署到互联网信息服务器（IIS）机器上时，它就不再正常运作了。出现的问题范畴包括从IIS配置不当到数据库连接字符串不正确。或者是某个程序集没有部署在IIS机器上。 谨在这儿分享一些我常用的调试技术来帮助系统管理员诊断部署的应用程序中的问题。关于如何配置网络服务器和部署LightSwitch应用程序，更多详细信息可参考Beth Massi’s deployment guide。

在我继续讲述之前，正确树立你的期待值。它不是万能的，不能解决你部署应用程序时遇到的所有问题。但是我可以提供一系列的步骤来诊断我们遇到的最常见的问题。每当有人对我说“我的应用程序出故障了”，我首先想到的事情就是这些步骤。如果这些步骤不能帮助你诊断问题所在，但它们至少提供了一些有用的信息，你可以把它们放到论坛里，在那儿或许有人可以帮到你。

可怕的红色X

在LightSwitch中，可怕的红色X类似于Xbox 360中的死亡之环，所以LightSwitch中出现红色X并没有那么悲惨。你没有必要用一个月的时间来修复。但是它也是你的应用程序中存在问题的一个重大暗示。当程序加载数据失败时，屏幕上将显示一个红色X。工具提示信息会出现“数据加载失败，请检查网络连接之后再重试”。

这些红色X实际上意味着在执行查询时，抛出了异常。

所以你该怎么做呢？

LightSwitch有一个少有人知的秘密，那就是它的服务器有一个与ASP.NET tracing相集成的诊断程序子系统。这个子系可以告诉你在运行查询时，哪个异常被抛出。同时它的功能远远比这更强大。你可以用它来追踪向服务器请求的行为以及服务器对每个行为所作的回应。所以即使所有事情看起来在运作，但你可以知道程序真正在做什么。

当创建一个新的LightSwitch应用程序时，默认情况下诊断是被禁用的。这是为性能和安全因素考虑。性能的原因是不言而喻的，即使是服务器上简单的追踪也会降低处理能力。出于安全因素是因为当诊断被允许时和当你允许远程机器来查看诊断时，任何使用你的应用程序的注册用户都可以获取诊断记录。

有5 个应用程序设置可以控制诊断程序子系统的行为：

Name

Possible values

Description

Microsoft.LightSwitch.Trace.Enabled

true, false

Enables diagnostic tracing on the server.  Default is false.

Microsoft.LightSwitch.Trace.LocalOnly

true, false

When set to false, allows machines other than IIS server to retrieve diagnostic information.  Default is true.

Microsoft.LightSwitch.Trace.Level

None, Error, Warning, Information, Verbose

Defines the level of trace information to be logged.  The values are in increasing order, i.e. Warning writes more log entries than Error.  Default is Information.

Microsoft.LightSwitch.Trace.Sensitive

true, false

Enables “sensitive” information to be written to the diagnostic log.  Sensitive means actual data values, such as addresses, balances, etc.  Default is false.

Microsoft.LightSwitch.Trace.Categories

Microsoft.LightSwitch, unlimited other values

The semi-colon separated list of categories that will be enabled at the specified trace level.  Default is Microsoft.LightSwitch.  Extensions may declare more, or you can declare new ones in your own app.

有两种方式可以使用LightSwitch诊断

在发布应用程序之前，修改web.config中的设置

想要修改web.config文件，将Solution Explorer 视图转换到“File View”

可以看出，在运行中的IIS 网络应用程序账号名下，“Login failed for user”出现了一个异常，这就告诉我——我的应用程序尝试用当前的账号来登录SQL Server数据库，然而，这个账号在我的数据库中没有被设置为用户。当我部署时忘了改变连接字符串。它在我的开发机上运行正常是因为在我的账号下运行。但是一旦我部署了，它就在另一个账号下运行了，而这个账号不具有权限来访问数据库。通过改变连接字符串来使用有效证书可以修复这个问题。

我刚才已经演示了如何诊断一个常见的问题：一旦应用程序被部署到外部，数据库证书就不再正常运行。然而，上述步骤可以诊断绝大多数应用程序中弹出来的红色X问题。你可能不会立刻发现问题，就像上面我所操作一样。但它依然可以详细告诉你问题所在。运用诊断程序子系统是每个LightSwitch开发人员应掌握的技巧。

“GetAuthenticationInfo”查询加载失败，远程服务器返回错误信息：没有找到相关资源

如果说之前所讲的红色X是可怕的，那么“GetAuthenticationInfo”的错误信息可能是可憎的。微软众员工花费了大量的时间正在试图去修复这个错误。可问题是，并不是仅仅一个问题可以导致这个错误。似乎有无穷尽的问题可以引起这个错误。这一原因上面已述。当加载应用程序时，“GetAuthenticationInfo”是LightSwitch发出的第一次服务请求。因此，如果你的IIS机器，网络应用程序，虚拟目录等等出现任何配置问题时，这个错误信息就会显示出来。不幸的是，在这种情况下使用上述诊断程序追踪并不能起到作用。很有可能，这个服务调用甚至没有进入到LightSwitch代码中。如此，诊断程序就无法记录信息，因为它不能到达那么远。

因此在这儿为了诊断问题，我们需要使用另一种工具——Fiddler。Fiddler 是每个网络开发人员与技术管理人员应该拥有，可供他们自由处理的工具。它记录了你的电脑与IIS网络服务器之间的所有网络流量。它可以追踪LightSwitch诊断程序所不能做到的。在客户机上下载Fiddler，启动程序，然后再次加载LightSwitch应用程序，在Fiddler里就可以看到网络请求和回应。

启动Fiddler时，你可以在左边看到请求，想要查看交互信息，点击顶部的“Inspectors”标签，为在顶部的请求和在底部的回应选择监视器。我的第三个请求，即“GetAuthenticationInfo”返回了一个回应——“500 – Internal Server Error”这个文档显示了服务器所做的回应。内容如下：

An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

这个信息显示出现了一个错误，但是服务器并没有显示错误的详细信息。所以我们需要配置服务器来找到错误。要做到这点，需要修改网络配置，按错误信息所述，添加“customErrors”部分，然后重新发布应用程序。或者你也可以在IIS Manager里修改设置。在IIS Manager里，导航到左边的Web Application。在“ASP.NET”标题下,双击“.NET Error Pages”。

在右边“Action”组下面，点击“Edit Feature Settings”

在“Edit Error Pages Settings”下，如果你的客户端是在另一台计算机上,选择“Off” ，或者如果你使用IIS机器作为客户端就选择“Remote Only”。

既然关闭了自定义错误，再次到达应用程序，查看Fiddler追踪情况。你应该会仍然得到“500 – Internal Server Error”错误信息，但是这个回应会提供更多信息告诉你错误所在。下面是我所获得的回应：

如你所看，错误信息为“无法识别的属性‘targetFramework’”。在Bing上快速搜索，错误信息显示，我需要确保服务于我的网站的应用程式集区设置为 4.0 framework。要修复这个错误，在IIS Manager右击“Contoso”网络应用程序，选择“Manage Application”–>“Advanced Settings”。将 Application Pool

从“Classic .NET AppPool”改为正确的“ASP.NET v4.0”。做了这些之后，重新加载应用程序，所有的事情都正常运行了。（说明：当使用LightSwitch配置时，Application Pool可以正确地设置，但是在我的例子中，有人偶然修改掉了。）

结论

就如我所说，这两种诊断技术不能解决部署LightSwitch应用程序后遇到的所有问题，但是它们可以先用来帮你决定发生了什么错误。希望这些信息能帮助你解决问题。转换到Bing搜索这个问题，或者转到LightSwitch论坛，使用这些信息来获取一个更快的解决方案。