Why are signed assemblies slow to load?

Question

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 t

Answer 1

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.

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.

Answer 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:

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

Answer 3

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

Answer 4

Have a look at these links:

• http://blogs.technet.com/markrussinovich/archive/2009/05/26/3244913.aspx
• http://blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx

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.

Answer 5

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

Answer 6

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