Pourquoi les assemblages signés sont-ils lents à charger?

Question

J'ai rencontré un problème étrange cette semaine que je ne peux pas expliquer: j'ai remplacé mon application par la version signée de certains assemblages tiers (Xceed Grid et certains de leurs autres composants) et le temps de démarrage de l'application est passé aux toilettes. . Chaque fois que l'application chargeait un assembly signé, le chargement prenait 30 secondes. Le démarrage de l'application est passé de 5 secondes à plus de 90 secondes. Que diable se passe-t-il ici?!

Quelques autres informations:

• Ceci est une application WinForms s'exécutant sous .NET 3.5 SP1.
• L'ordinateur n'avait pas de connexion Internet (à des fins de sécurité).

Answer 1

Consultez ces liens:

• 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

Ils pourraient aider. Il se peut que la configuration de votre système signifie que le framework .NET fait beaucoup de travail supplémentaire pour vérifier l’assemblage. Si tel est le cas, vous pouvez le configurer pour qu'il ne soit pas aussi pointilleux.

Answer 2

Le message de Jason Evans contient la réponse, mais sous la forme d'un lien. Je pensais que ce serait bien d’afficher la solution actuelle ici:

Créez un fichier Appname.exe.config dans le même dossier que l'exécutable (où Appname est le nom de votre exécutable; pour le développement, il figurerait dans le dossier de sortie du débogage). Cela montre un fichier XML qui suppose que vous n’avez pas d’autres entrées dans le fichier de configuration principal; si vous avez déjà le fichier, je suppose que vous ajouteriez simplement les nouvelles sections / texte si nécessaire:

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

Answer 3

Si quelqu'un d'autre trouve ce message, j'ai tracé la question un peu plus loin, car j'essayais simplement de le comprendre et de trouver cette page.

Il semble que la liste de révocation de certificats soit vérifiée chaque fois que vous exécutez votre processus si la liste de révocation de certificats existante figurant sur votre ordinateur a expiré et si elle n'a pas encore été mise à jour. Vous pouvez tester cela en consultant la liste de révocation de certificats à l'adresse http://crl.microsoft.com/. pki / crl / products / CodeSignPCA.crl et vérifiez la date d'expiration. Configurez maintenant un proxy dans IE qui ne fonctionne pas. Définissez la date de votre machine au-delà de la date d'expiration et testez à nouveau votre application.

Si votre carte réseau est désactivée, la liste de révocation de certificats n'est pas vérifiée.

Si votre carte réseau ne possède pas de passerelle, la liste de révocation de certificats n'est pas vérifiée.

Si un proxy et une passerelle sont activés, la liste de révocation de certificats est vérifiée. En cas de problème avec le proxy, vous rencontrez ce problème.

Si vous vous connectez à Internet avec succès, la liste de révocation de certificats est mise à jour et tout ira bien pour le moment.

Mon application utilisait d'anciens composants Xceed dans .NET 2.0 et fonctionnait depuis toujours. Il a donc fallu un certain temps pour comprendre ce qui se passait.

Answer 4

Le chargement des assemblys signés sera certainement plus lent que leurs homologues non signés car la signature doit être vérifiée, mais cela doit être complètement négligeable.

Passage de 5 secondes à 90 secondes ?? Je pense que vous devez contacter l’auteur de l’assemblée et lui demander s’il n’a modifié que la signature: -)

Answer 5

Je suppose que les paramètres de sécurité sont définis de manière à ce que les certificats d'assemblages soient vérifiés. Il essaie donc probablement d’accéder au Web pour vérifier un certificat, puis attend un délai d’attente (30 secondes correspond à un numéro de délai d’expiration TRÈS typique).

Vous pouvez le vérifier si vous regardez ce qui se passe dans ces 30 secondes. Pour que mes hypothèses soient vraies, il devrait y avoir peu d'utilisation du processeur et peu d'accès au disque dur en 90 secondes. Si vous utilisez beaucoup de ressources processeur ou êtes lié par votre disque dur, c’est autre chose.

BTW: Une autre option serait que votre disque dur soit complètement plein et que les assemblages soient EXTRÊMEMENT fragmentés (mais 90 secondes seraient plus longues que celles dont j'avais jamais entendu parler dans ce cas).

Answer 6

Essayez de démarrer votre application à partir de Visual Studio avec "Pas à pas". Cela démarrera le code en passant au-dessus de chaque application, afin que vous puissiez vérifier ce qui prend si longtemps. Une fois, j’ai eu cela, et il s’est avéré que mon serveur SQL était vraiment foiré.

Une autre façon de savoir pourquoi cela prend tant de temps consiste à placer des points d'arrêt dispersés dans le code de chargement et à voir le goulot d'étranglement. Si l'application prend 90 secondes avant , votre commence par ressembler, probablement à quelque chose avec XCeed, ou à charger les assemblys signés.

Btw, je suis conscient du fait qu'il existe de meilleurs moyens de profiler votre application, mais cette méthode rapide fonctionne mal et efficace pour déboguer de tels problèmes

Answer 7

Peut-être que les assemblys signés ne sont pas NGEN, alors que ceux non signés le sont.