我遇到一个奇怪的问题,这个星期我无法解释:我交换我的应用程序使用的某些第三方组件(Xceed电网和他们的一些其他组件)和应用程序的签名版本开始时间走进了厕所。 每次加载应用程序签名的程序集,它花了30秒加载。 应用开始从5秒增长到90秒。 到底是什么怎么回事?
其他一些信息:
- 这是在.NET 3.5 SP1上运行的WinForms应用程序。
- 计算机没有互联网连接(有目的的,出于安全考虑)。
我遇到一个奇怪的问题,这个星期我无法解释:我交换我的应用程序使用的某些第三方组件(Xceed电网和他们的一些其他组件)和应用程序的签名版本开始时间走进了厕所。 每次加载应用程序签名的程序集,它花了30秒加载。 应用开始从5秒增长到90秒。 到底是什么怎么回事?
其他一些信息:
看看这些链接:
他们可能会有所帮助。 这可能是因为您的系统上的配置意味着.NET Framework是做了很多额外的工作来验证组装。 如果是这样的话,那么你可以将其配置为不那么挑剔。
杰森·埃文斯后确实包含了答案,但在一个链接的形式。 我认为这将是很好的,张贴在这里实际的解决方案:
创建在同一文件夹作为可执行文件Appname.exe.config(其中,appname是你的可执行文件的名称;发展,这将是在调试输出文件夹)。 这表明,假设你没有在主配置文件中的其他条目的XML文件; 如果你有文件了,我想你也只是根据需要添加新的章节/文字:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false" />
</runtime>
</configuration>
只是柜面任何人遇到这个职位,我追踪的问题远一点,因为我只是想弄清楚,并找到了这个网页。
看来,CRL是您运行的过程中,如果现有的CRL是您的机器上已超时,并没有用一个新的更新,每次检查。 您可以通过点击CRL在测试这个http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl和检查失效日期。 现在配置中IE代理不起作用。 将机器设置为过去的日期到期日并重新测试您的应用程序。
如果你的网卡被禁用时,CRL不检查。
如果你的网卡没有网关时,CRL不检查。
如果你启用了代理和网关,则CRL被选中,如果没有与代理问题,那么你会遇到这种超时。
如果你连接到互联网成功则CRL更新,你将被罚款暂且。
我的应用程序是使用一些旧的Xceed组件在.NET 2.0,并已永远地工作,所以花了一段时间才能找出发生了什么事情。
因为签名需要验证,但是这应该是完全可以忽略不计加载签名程序绝对会比非签约同行慢 。
从5秒传递至90秒?? 我认为你需要联系装配作者,问他们是否只更改了签名:-)
我猜想,你的方式,使得组件的证书进行验证设置的安全设置。 因此,它可能会尝试访问网络来验证一些证书,然后等待超时(30秒是一个非常典型的超时数)。
如果你看一下在30秒发生什么事情,您可以验证这一点。 对于我的猜测是正确的,应该是很少的CPU使用率,硬盘很少在那些90秒访问。 如果你有高CPU使用或通过您的硬盘有关联,那么它是别的东西。
BTW:另一种选择是,如果你的硬盘是完全充分和组件非常分散(但90秒将超过我曾经在这种情况下听到的)。
尝试使用“步过”开始从Visual Studio你的应用程序。 这将通过加强在每个应用程序启动代码,这样你就可以检查什么需要这么长时间。 我曾经有过这一点,事实证明,我的SQL Server真的搞砸了。
找出为什么需要这么长的另一种方法是把断点通过加载代码散见的瓶颈是什么。 如果应用程序之前,这是您第一样,可能是一些与XCeed,或加载签名程序需要90秒。
顺便说一句,即时通讯知道有更好的方法来分析你的应用程序,但这种快速“N脏的工作方式相当不错的,高效的调试这样的问题
也许签名程序不NGEN'd,而签名的有。