Warum werden vorzeichenbehaftete Assemblierungen langsam geladen?

Question

Ich habe diese Woche ein seltsames Problem festgestellt, das ich nicht erklären kann: Ich habe meine Anwendung so umgestellt, dass sie die signierte Version einiger Drittanbieter-Assemblys (Xceed Grid und einige ihrer anderen Komponenten) verwendet und die Startzeit der Anwendung in die Toilette gegangen ist. Jedes Mal, wenn die Anwendung eine signierte Assembly geladen hat, dauerte das Laden 30 Sekunden. Der Anwendungsstart ging von 5 Sekunden auf über 90 Sekunden. Was zum Teufel geht hier vor ?!

Einige andere Info:

• Dies ist eine WinForms-Anwendung unter .NET 3.5 SP1 ausgeführt wird.
• Der Computer hatte keine Internetverbindung (absichtlich, zur Sicherheit).

Answer 1

Werfen Sie einen Blick auf diese Links gilt:

• 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

Sie helfen könnten. Es könnte sein, dass die Konfiguration auf Ihrem System bedeutet, dass das .NET-Framework eine Menge zusätzlicher Arbeit zur Überprüfung der Assembly benötigt. Wenn dies der Fall ist, können Sie es so konfigurieren, dass es nicht so wählerisch ist.

Answer 2

Laden unterzeichnet Baugruppen werden auf jeden Fall sein langsamer als nicht-signierte Pendants, weil Signatur überprüft werden muss, aber dies sollte völlig vernachlässigbar sein.

Überschreiten von 5 Sekunden bis 90 Sekunden ?? Ich denke, Sie müssen den Assembly Autor kontaktieren und fragen, ob sie nur die Signatur geändert haben :-)

Answer 3

Vielleicht sind die signierten Assemblys nicht NGEN'd, während die unsigned sind.

Answer 4

Ich würde vermuten, dass Sie die Sicherheitseinstellungen so eingestellt haben, dass die Assembly-Zertifikate überprüft werden. Daher versucht es wahrscheinlich, auf das Web zuzugreifen, um ein Zertifikat zu überprüfen, und wartet dann auf ein Timeout (30 Sekunden ist eine SEHR typische Timeout-Nummer).

Sie können dies überprüfen, wenn Sie sich ansehen, was in diesen 30 Sekunden passiert. Ich denke, dass es in diesen 90 Sekunden nur wenig CPU-Nutzung und wenig Festplattenzugriffe geben sollte. Wenn Sie eine hohe CPU-Auslastung haben oder an Ihre Festplatte gebunden sind, ist es etwas anderes.

BTW: Eine andere Option wäre, wenn Ihre Festplatte voll ist und die Baugruppen EXTREM fragmentiert sind (aber 90 Sekunden wären mehr als ich jemals in diesem Fall gehört habe).

Answer 5

Versuchen Sie, Ihre Anwendung von Visual Studio mit "Step over" zu starten. Dies startet den Code, indem Sie über jede App gehen, so dass Sie überprüfen können, was so lange dauert. Ich hatte das einmal, und es stellte sich heraus, dass mein SQL Server wirklich durcheinander war.

Eine andere Möglichkeit, herauszufinden, warum es so lange dauert, ist, den Haltepunkt durch den Ladecode zu verteilen und zu sehen, was der Engpass ist. Wenn die Anwendung dauert 90 Sekunden vor es Ihre zuerst wie, wahrscheinlich etwas mit XCeed, oder Laden der signierten Baugruppen.

Btw, ich bin bewusst, es gibt bessere Möglichkeiten, um Ihre Anwendung zu profilieren, aber diese kurze Nachricht ‚n schmutzige Art und Weise funktioniert recht nett und effizient solche Probleme

Answer 6

Jason Evans zu debuggen‘ tut die Antwort enthalten, sondern in Form einer Verbindung. Ich dachte, es wäre gut, die tatsächliche Lösung hier zu posten:

Erstellen Sie eine Datei Appname.exe.config im selben Ordner wie die ausführbare Datei (wobei Appname der Name Ihrer ausführbaren Datei ist; für die Entwicklung wäre dies in der Debug-Ausgabeordner). Dies zeigt eine XML-Datei an, die davon ausgeht, dass Sie keine anderen Einträge in der Hauptkonfigurationsdatei haben. Wenn Sie die Datei bereits haben, gehe ich davon aus Sie würde nur die neuen Abschnitte/Text wie nötig hinzufügen:

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

Answer 7

Nur incase jemand anderes in diesem Beitrag kommt, habe ich das Problem ein wenig weiter verfolgt, weil ich Ich versuche es herauszufinden und habe diese Seite gefunden.

Es scheint, dass die CRL jedes Mal überprüft wird, wenn Sie Ihren Prozess ausführen, wenn die vorhandene CRL auf Ihrem Computer abgelaufen ist und noch nicht mit einem neuen aktualisiert wurde. Sie können dies testen, indem Sie die CRL unter http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl ankreuzen und das Ablaufdatum überprüfen. Konfigurieren Sie nun einen Proxy innerhalb von IE, der nicht funktioniert. Stellen Sie Ihr Maschinendatum nach dem Ablaufdatum ein und testen Sie Ihre Anwendung erneut.

Wenn Ihre Netzwerkkarte deaktiviert ist, wird die CRL nicht überprüft.

Wenn Ihre Netzwerkkarte kein Gateway hat, wird die CRL nicht überprüft.

Wenn Sie einen Proxy aktiviert haben und ein Gateway, wird die CRL überprüft und wenn es ein Problem mit dem Proxy gibt, dann wird diese Zeitüberschreitung auftreten.

Wenn Sie erfolgreich mit dem Internet verbunden sind, wird die CRL aktualisiert und Sie werden vorerst in Ordnung sein.

Meine Anwendung verwendete einige ältere Xceed-Komponenten in .NET 2.0 und hat für immer gearbeitet, so dass es eine Weile dauerte, um herauszufinden, was vor sich ging.