blocks|key|1102697|text|也许签名的程序集不是NGEN的，而未签名的程序集是NGEN的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1102698|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|2627117|text|请查看以下链接：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2627118|https://web.archive.org/web/20120812062059/http://blogs.technet.com/b/markrussinovich/archive/2009/05/26/3244913.aspx+-慢基调演示的案例(Mark的博客)
现在，我确信启动延迟的原因是.NET看到Stockviewer.exe被签名，然后检查签名证书是否被撤销，所以我进入网络搜索，寻找一种让.NET跳过检查的方法，因为我知道在实际的主题演讲期间，主题机器可能不会连接到互联网上。在阅读了几分钟的其他有类似经验的文章之后，我发现这个KB文章+.
..。程序集数字签名检查:在可执行文件目录中创建一个配置文件，其名称与可执行文件相同，但附加了“.config”|unordered-list-item|offset|length|2627119|他们也许能帮上忙。您的系统上的配置可能意味着.NET框架正在做大量额外的工作来验证程序集。如果是这样的话，那么您可以将其配置为不那么挑剔。|2627120|https://web.archive.org/web/20130409115103/http://blogs.msdn.com/b/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx+-+ASP.NET+Hang:+Authenticode签名程序集(如果它坏了，您应该修复它，由ASP.NET升级工程师苔丝·费兰德斯编写)|2627121|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.technet.com/markrussinovich/archive/2009/05/26/3244913.aspx|1|https://web.archive.org/web/20120814091547/http://support.microsoft.com/kb/936707|2|http://blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx^0|0|0|39|0|7N|4|1|0|0|0|3V|2|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@$E|Y|F|Z|1|10]|$E|11|F|12|1|13]]|A|$]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|15|8|@]|9|@$E|16|F|17|1|18]]|A|$]]|$1|K|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]|S|$5|N|O|P|A|$Q|T]]|U|$5|N|O|P|A|$Q|V]]]]

Have a look at these links:
<ul>
<li><a href="http://blogs.technet.com/markrussinovich/archive/2009/05/26/3244913.aspx" rel="nofollow noreferrer">https://web.archive.org/web/20120812062059/http://blogs.technet.com/b/markrussinovich/archive/2009/05/26/3244913.aspx</a> - The Case of the Slow Keynote Demo (Mark Russinovich’s Blog)
<blockquote>
Confident now that the cause of the startup delay was due to .NET seeing that Stockviewer.exe was signed and then checking to see if the signing certificate had been revoked, I entered Web searches looking for a way to make .NET to skip the check, since I knew that the keynote machines probably wouldn’t be connected to the Internet during the actual keynote. After a couple of minutes of reading through articles by others with similar experiences, I found this <a href="https://web.archive.org/web/20120814091547/http://support.microsoft.com/kb/936707" rel="nofollow noreferrer">KB article</a> ...
... checking of assembly digital signatures: create a configuration file in the executable’s directory with the same name as the executable except with “.config” appended
</blockquote>
<blockquote>
<pre><code>&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt;
&lt;configuration&gt;
 &lt;runtime&gt;
 &lt;generatePublisherEvidence enabled=&quot;false&quot;/&gt;
 &lt;/runtime&gt;
&lt;/configuration&gt;
</code></pre>
</blockquote>
</li>
</ul>
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.
<ul>
<li><a href="http://blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx" rel="nofollow noreferrer">https://web.archive.org/web/20130409115103/http://blogs.msdn.com/b/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx</a> - ASP.NET Hang: Authenticode signed assemblies (If broken it is, fix it you should, by Tess Ferrandez, ASP.NET Escalation Engineer)</li>
</ul>

blocks|key|1102821|text|我猜您的安全设置是以某种方式设置的，以便验证程序集证书。因此，它可能会尝试访问web来验证某些证书，然后等待超时(30秒是一个非常典型的超时数字)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1102822|如果你看看30秒内发生了什么，你就可以验证这一点。对于我的猜测是正确的，应该有很少的CPU使用和很少的HDD访问在这90秒。如果您有较高的CPU使用率或绑定您的HDD，那么这是另外的东西。|1102823|顺便说一句:另一种选择是，如果您的HDD已经完全满，并且程序集非常分散(但是90秒比我在这种情况下所听说的要多)。|1102824|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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).

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.

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).

blocks|key|1081813|text|尝试用“跨一步”从visual+studio启动应用程序。这将通过遍历每个应用程序来启动代码，这样您就可以检查什么花费了这么长时间。我曾经有过这样的经历，结果发现我的sql服务器真的很糟糕。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1081814|另一种了解为什么要花这么长时间的方法是将断点分散在加载代码中，并查看瓶颈是什么。如果应用程序在开始运行前需要90秒的时间，那么您可能需要使用XCeed，或者加载已签名的程序集。|1081815|顺便说一句，我意识到有更好的方法来分析您的应用程序，但是这种快速的脏方式可以很好地有效地调试这些问题。|1081816|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

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. 

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

blocks|key|1082373|text|杰森·埃文斯的帖子确实包含了答案，但以链接的形式出现。我认为在这里贴出实际的解决方案会更好：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1082374|在与可执行文件相同的文件夹中创建一个文件Appname.exe.config+(其中Appname是可执行文件的名称；对于开发，这将在调试输出文件夹中)。这显示了一个xml文件，它假定您在主配置文件中没有其他条目；如果您已经拥有了该文件，我假设您只需要添加新的部分/文本：|1082375|<?xml+version="1.0"+encoding="utf-8"?>
<configuration>
++++<runtime>
++++++++<generatePublisherEvidence+enabled="false"+/>
++++</runtime>
</configuration>|code-block|syntax|javascript|1082376|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

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:

<pre><code>&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;configuration&gt;
 &lt;runtime&gt;
 &lt;generatePublisherEvidence enabled="false" /&gt;
 &lt;/runtime&gt;
&lt;/configuration&gt;
</code></pre>

blocks|key|1082386|text|为了防止其他人看到这篇文章，我对这个问题做了进一步的追踪，因为我只是想弄清楚这个问题，并找到了这个页面。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1082387|如果计算机上的现有CRL已超时，且尚未用新的CRL更新，则每次运行进程时，似乎都会检查CRL。您可以通过在http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl上点击CRL并检查过期日期来测试这一点。现在，在IE中配置一个不能工作的代理。将计算机日期设置为过期日期，并重新测试应用程序。|offset|length|1082388|如果禁用NIC，则不检查CRL。|1082389|如果您的NIC没有网关，则不检查CRL。|1082390|如果启用了代理和网关，则检查CRL，如果代理出现问题，则将经历此超时。|1082391|如果您成功地连接到互联网，那么CRL将更新，您将暂时没事。|1082392|我的应用程序在.NET+2.0中使用了一些旧的Xceed组件，并且一直在工作，所以需要一段时间才能弄清楚到底是怎么回事。|1082393|entityMap|0|LINK|mutability|MUTABLE|url|http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl^0|0|1H|1L|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]]]

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 <a href="http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl" rel="noreferrer">http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl</a> 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.

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

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

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.

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

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.

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?!

Some other info:

<ul>
<li>This is a WinForms app running under .NET 3.5 SP1.</li>
<li>The computer had no internet connection (on purpose, for security).</li>
</ul>

Why are signed assemblies slow to load?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

本周，我遇到了一个无法解释的奇怪问题:我切换了应用程序，使用了一些第三方程序集(Xceed Grid和其他一些组件)的签名版本，应用程序启动时间进入了厕所。每次应用程序加载一个签名的程序集时，加载时间都是30秒。应用程序开始时间从5秒到90秒以上。这到底是怎么回事？！其他一些信息：这是一个WinForms应用程序，运行...

问为什么已签名的程序集加载速度慢？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么已签名的程序集加载速度慢？EN