这周我遇到了一个无法解释的奇怪问题:我将我的应用程序切换为使用一些第三方程序集(Xceed Grid 和它们的一些其他组件)的签名版本,并且应用程序的启动时间变得很糟糕。每次应用程序加载签名的程序集时,都会花费 30 秒的时间来加载。应用程序启动时间从 5 秒缩短到 90 秒以上。这到底是怎么回事?

其他一些信息:

  • 这是一个在 .NET 3.5 SP1 下运行的 WinForms 应用程序。
  • 该计算机没有互联网连接(出于安全目的故意)。
有帮助吗?

解决方案

看看这些链接:

他们可能会有所帮助。您系统上的配置可能意味着 .NET 框架正在执行大量额外工作来验证程序集。如果是这种情况,那么您可以将其配置得不那么挑剔。

其他提示

Jason Evans 的帖子确实包含答案,但以链接的形式。我认为在这里发布实际的解决方案会很好:

在与可执行文件相同的文件夹中创建文件 Appname.exe.config(其中 Appname 是可执行文件的名称;对于开发,这将位于调试输出文件夹中)。这显示了一个 xml 文件,该文件假定主配置文件中没有其他条目;如果您已经有了该文件,我假设您只需根据需要添加新的部分/文本:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false" />
    </runtime>
</configuration>

为了防止其他人看到这篇文章,我进一步追踪了这个问题,因为我只是想弄清楚并找到了这个页面。

如果您计算机上的现有 CRL 已超时且尚未使用新 CRL 进行更新,则每次运行进程时都会检查 CRL。您可以通过点击 CRL 来测试这一点 http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl 并检查有效期。现在在 IE 中配置一个代理不起作用。将您的机器日期设置为过期日期并重新测试您的应用程序。

如果您的 NIC 被禁用,则不会检查 CRL。

如果您的 NIC 没有网关,则不会检查 CRL。

如果您启用了代理和网关,则会检查 CRL,如果代理存在问题,您将遇到此超时。

如果您成功连接到互联网,那么 CRL 就会更新,您暂时就可以了。

我的应用程序在 .NET 2.0 中使用一些较旧的 Xceed 组件,并且一直在工作,因此花了一段时间才弄清楚发生了什么。

加载签名的程序集肯定会 慢点 与未签名的副本相比,因为签名需要验证,但这应该完全可以忽略不计。

从5秒变成90秒??我认为您需要联系程序集作者并询问他们是否仅更改了签名:-)

我猜您已经以某种方式设置了安全设置,以便验证程序集证书。因此,它可能会尝试访问网络来验证某些证书,然后等待超时(30 秒是非常典型的超时数字)。

如果您查看这 30 秒内发生的情况,就可以验证这一点。根据我的猜测,在这 90 秒内应该很少有 CPU 使用和 HDD 访问。如果您的 CPU 使用率很高或受 HDD 限制,那就是另一回事了。

顺便提一句:另一种选择是,如果您的 HDD 已完全满并且程序集极其分散(但在这种情况下 90 秒将比我听说过的更长)。

尝试使用“Step over”从 Visual Studio 启动您的应用程序。这将通过单步执行每个应用程序来启动代码,以便您可以检查什么需要这么长时间。我曾经遇到过这样的情况,结果发现我的sql服务器真的很混乱。

找出为什么需要这么长时间的另一种方法是在加载代码中分散放置断点,看看瓶颈是什么。如果应用程序需要 90 秒 你的 首先,可能是 XCeed 的一些东西,或者加载签名的程序集。

顺便说一句,我知道有更好的方法来分析您的应用程序,但是这种快速而肮脏的方法对于调试此类问题非常有效且有效

也许签名的程序集不是 NGEN 的,而未签名的程序集是 NGEN 的。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top