这周我遇到了一个我无法解释的奇怪问题:我将我的应用程序切换为使用一些第三方程序集(Xceed Grid 和它们的一些其他组件)的签名版本,并且应用程序启动时间进入了厕所。每次应用程序加载签名程序集时,加载需要 30 秒。应用程序启动时间从 5 秒增加到 90 秒以上。这到底是怎么回事?!
其他一些信息:
- 这是一个在 .NET 3.5 SP1 下运行的 WinForms 应用程序。
- 计算机没有互联网连接(出于安全考虑)。
这周我遇到了一个我无法解释的奇怪问题:我将我的应用程序切换为使用一些第三方程序集(Xceed Grid 和它们的一些其他组件)的签名版本,并且应用程序启动时间进入了厕所。每次应用程序加载签名程序集时,加载需要 30 秒。应用程序启动时间从 5 秒增加到 90 秒以上。这到底是怎么回事?!
其他一些信息:
Jason Evans 的帖子确实包含答案,但是以链接的形式。我认为在这里发布实际解决方案会很好:
在与可执行文件相同的文件夹中创建文件 Appname.exe.config(其中 Appname 是可执行文件的名称;对于开发,这将位于调试输出文件夹中)。这显示了一个 xml 文件,假设您在主配置文件中没有其他条目;如果您已经拥有该文件,我假设您只需根据需要添加新的部分/文本:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false" />
</runtime>
</configuration>
看看这些链接:
他们可能会有所帮助。可能是您系统上的配置意味着 .NET 框架正在做很多额外的工作来验证程序集。如果是这种情况,那么您可以将其配置为不那么挑剔。
以防万一其他人看到这篇文章,我已经进一步追踪了这个问题,因为我只是想弄清楚并找到了这个页面。
如果您机器上的现有 CRL 已超时,并且尚未使用新的 CRL 更新,则每次运行进程时似乎都会检查 CRL。您可以通过点击http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl上的 CRL 来测试它并检查到期日期。现在在 IE 中配置一个不起作用的代理。将您的机器日期设置为过期日期并重新测试您的应用程序。
如果您的 NIC 被禁用,则不会检查 CRL。
如果您的 NIC 没有网关,则不会检查 CRL。
如果您启用了代理和网关,则会检查 CRL,如果代理有问题,您将遇到此超时。
如果您成功连接到 Internet,则 CRL 会更新,您暂时会没事的。
我的应用程序在 .NET 2.0 中使用了一些较旧的 Xceed 组件,并且一直在工作,所以花了一段时间才弄清楚发生了什么。
加载签名的程序集肯定会比未签名的程序集慢,因为需要验证签名,但这应该完全可以忽略不计。
从5秒到90秒??我认为您需要联系程序集作者并询问他们是否仅更改了签名:-)
我猜您的安全设置以某种方式设置,以便程序集证书得到验证。因此它可能会尝试访问网络以验证某些证书,然后等待超时(30 秒是一个非常典型的超时数)。
如果您查看这 30 秒内发生的情况,您可以验证这一点。对于我的猜测,在这 90 秒内应该很少使用 CPU 和很少的 HDD 访问。如果您的 CPU 使用率很高或受 HDD 的限制,那就另当别论了。
顺便说一句:另一种选择是,如果您的 HDD 完全装满并且组件非常碎片化(但在这种情况下,90 秒将比我听说过的要多)。
尝试使用“Step over”从 Visual Studio 启动您的应用程序。这将通过遍历每个应用程序来启动代码,因此您可以检查需要这么长时间。我曾经有过这个,结果我的sql server真的很乱。
找出为什么需要这么长时间的另一种方法是在加载代码中分散放置断点并查看瓶颈是什么。如果应用程序在您第一次喜欢之前需要90 秒,可能是 XCeed 或加载签名的程序集。
顺便说一句,我知道有更好的方法来分析您的应用程序,但是这种快速的“肮脏的方式”在调试此类问题时非常有效且有效
也许签名的程序集不是 NGEN 的,而未签名的程序集是。