为什么签名的程序集加载缓慢？

I encountered a strange problem this week that I can't explain: I switched my application to use the signed version of some third party assemblies (Xceed Grid and some of their other components) and the application start time went into the toilet. Each time the application loaded a signed assembly, it took 30 seconds to load. Application start went from 5 seconds to over 90 seconds. What the heck is going on here?!

我本周遇到一个奇怪的问题,我无法解释:我将我的应用程序切换为使用某些第三方程序集(Xceed Grid和其他一些组件)的签名版本,并且应用程序启动时间进入了厕所。每次应用程序加载已签名的程序集时,都需要30秒才能加载。应用程序启动从5秒到超过90秒。这到底是怎么回事?!

Some other info:

其他一些信息:

This is a WinForms app running under .NET 3.5 SP1.

这是在.NET 3.5 SP1下运行的WinForms应用程序。

The computer had no internet connection (on purpose, for security).

计算机没有互联网连接(为了安全起见,故意)。

7 个解决方案

#1

Have a look at these links:

看看这些链接:

They might help. It could be that the config on your system means that the .NET framework is doing a lot of extra work to verify the assembly. If this is the case, then you can configure it to not be so picky.

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

#2

Jason Evans' post does contain the answer, but in the form of a link. I thought it would be good to post the actual solution here:

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

Create a file Appname.exe.config in the same folder as the executable (where Appname is the name of your executable; for development, this would be in the debug output folder). This shows an xml file that assumes you don't have other entries in the main config file; if you have the file already, I assume you would just add the new sections/text as necessary:

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

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

#3

Just incase anyone else comes across this post, I've traced the issue a little further, because I was just trying to figure it out and found this page.

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

It appears that the CRL is checked each time you are running your process if the existing CRL that is on your machine has timed out, and not yet updated with a new one. You can test this by hitting the CRL at http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl and check the expiry date. Now configure a Proxy within IE that doesn't work. Set your machine date past the Expiry Date and retest your application.

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

If your NIC is disabled, the CRL is not checked.

如果禁用了NIC,则不会检查CRL。

If your NIC has no gateway, the CRL is not checked.

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

If you have a Proxy enabled and a gateway then the CRL is checked and if there is a problem with the Proxy, then you will experience this timeout.

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

If you connect to the internet successfully then the CRL updates and you will be fine for the time being.

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

My application was using some older Xceed Components in .NET 2.0 and has been working forever so it took a while to figure out what was going on.

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

#4

Loading signed assemblies will definitely be slower than non-signed counterparts because signature needs to be verified, but this should be completely negligible.

加载已签名的程序集肯定会慢于非签名程序集,因为需要验证签名,但这应该完全可以忽略不计。

Passing from 5 seconds to 90 seconds?? I think you need to contact the assembly author and ask them if they changed only the signature :-)

从5秒到90秒?我想你需要联系大会作者并询问他们是否只更改了签名:-)

#5

I would guess that you have the security settings set in a way so that the assemblies certificates get verified. So it likely tries to access the web to verify some certificate and then waits for a timeout (30 sec is a VERY typical timeout number).

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

You can verify this if you look at what happens in that 30 seconds. For my guess to be true there should be little CPU use and little HDD accesses in those 90 seconds. If you have high CPU use or bound by your HDD then it's something else.

如果您查看30秒内发生的情况,可以验证这一点。因为我的猜测是真的,在90秒内应该有很少的CPU使用和很少的硬盘访问。如果您的CPU使用率很高或受到硬盘绑定,那么它就是其他东西。

BTW: Another option would be if your HDD is completely full and the assemblies are EXTREMELY fragmented (but 90 secs would be more than I ever heard of in that case).

顺便说一句:另一种选择是如果你的硬盘已满,而且组件非常碎片(但在这种情况下90秒会比我听说过的多)。

#6

Try to start you application from visual studio with "Step over". This will start the code by stepping over each app, so you can check what takes so long. I once had this, and it turned out that my sql server was really messed up.

尝试使用“Step over”从visual studio启动应用程序。这将通过单步执行每个应用程序来启动代码,这样您就可以查看需要这么长时间的内容。我曾经有过这个,事实证明我的SQL服务器真的搞砸了。

Another way to find out why it takes so long is to place breakpoint scattered through the loading code and see what the bottleneck is. If the application takes 90 seconds before it your first like, probably something with XCeed, or loading the signed assemblies.

另一种找出为什么需要这么长时间的方法是将断点分散在加载代码中,看看瓶颈是什么。如果应用程序在您第一次使用之前需要90秒,可能需要使用XCeed,或者加载已签名的程序集。

Btw, im aware there are better ways to profile your application, but this quick 'n dirty way works quite nice and efficient to debug such problems

顺便说一句,我知道有更好的方法来分析你的应用程序,但这种快速的脏方法可以非常有效地调试这些问题

#7

Maybe the signed assemblies are not NGEN'd, while the unsigned ones are.

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

#1