J'ai un processus de ligne de commande qui crée un fichier PDF à partir d'un fichier HTML à l'aide d'ABCPDF. J'essaie de passer de V5 (très vieux, n'est plus supporté) à V8, mais après avoir installé ABCPDF 8 et à la mise à jour de mon application pour utiliser la nouvelle DLL, j'ai remarqué que le processus qui prenait moins d'une seconde pour convertir prend maintenant plus de 20 secondes.
J'ai ajouté des appels de trace dans le code et il apparaît que le point où le programme tente de référencer un objet de la DLL ABCPDF 8 est l'endroit où les choses font une pause pendant une bonne période. Une fois que le code a passé ce point, il fonctionne aussi vite que jamais.
La question que j'ai est: qu'est-ce qui pourrait amener le CLR à ralentir tant pour tenter de faire référence à une bibliothèque tierce? J'ai vérifié que la DLL ABCPDF 8 est dans le GAC ainsi que le même répertoire que l'exécutable.
Merci d'avance.
3 Réponses :
Out sur un membre, laissez-moi deviner:
Vous exécutez ceci sur un serveur sans connectivité Internet (sortant) Internet. p>
Le composant est fort et signé avec une clé cryptographique. Le certificat est en cours de vérification (la liste de révocation est vérifiée si le certificat est toujours valide et approuvé). Cette fois-ci, en raison de l'absence d'une connexion Internet. P>
Si vous souhaitez confirmer cela, joignez un débogueur (Windbg?) Et confirmez la structure de pile suivante sur l'un des threads: P>
0e82c1b4 7c822124 ntdll!KiFastSystemCallRet 0e82c1b8 77e6bad8 ntdll!NtWaitForSingleObject+0xc 0e82c228 73ca64ec kernel32!WaitForSingleObjectEx+0xac 0e82c254 73ca6742 cryptnet!CryptRetrieveObjectByUrlWithTimeout+0x12f
Cela semble être le problème. J'ai désactivé la "vérification de l'éditeur" Option avancée de la révocation de l'éditeur dans les options Internet pour vérifier et que le problème s'est éloigné. En fin de compte, nous allons ouvrir suffisamment notre pare-feu pour laisser la boîte à frapper crl.microsoft.com (le serveur de liste de révocation) qui devrait corriger le problème à l'avenir. Ou peut-être que nous utiliserons le code dans la réponse ci-dessous pour le désactiver pour cette bibliothèque, pas encore sûr. Quoi qu'il en soit, merci pour le point dans la bonne direction.
Si c'est le problème cryptograpique, vous pouvez le résoudre à l'aide de l'entrée Followng App.Config.
Mais Afaik, ce n'est qu'un problème si l'ordinateur a DNS, mais aucune autre connexion Internet n'est disponible (pare-feu).
J'ai eu un problème très similaire qui était lors de l'utilisation du moteur Gecko, il faudrait 45 secondes pour créer le premier PDF. Une fois commencé, c'était OK.
Le problème était causé parce que notre serveur Prod n'avait aucune connectivité sortante. Pour résoudre ce problème, un paramètre de stratégie de groupe peut être modifié pour définir le délai d'attente sur 1 seconde. Voir:
http://technet.microsoft.com/en-us/library/ CC753863.aspx
Pour les étapes sur la façon de faire cela.
Pause le débogueur pendant cette période et regarder la pile d'appels.
Est-ce seulement lent lorsque le studio visuel (ou un autre débogueur) est-il joint?
Votre application est-elle une application 4NET 4 pendant que la DLL est ".NET 2"? Selon certains paramètres, le CLR de .NET 4 peut-il avoir besoin de charger le fichier .NET 2 CLR (Ceci est une nouvelle fonctionnalité de .NET 4)?
Je n'ai pas encore attaché un débogueur. La machine avec laquelle je rencontre le problème ne dispose pas de Visual Studio (un serveur Web). L'application devrait exécuter .NET 3.5 mais je revérifierai cela.
Utilisez FuslogVwr.EXe pour savoir si la DLL charger d'autres dll.
La DLL ABCPDF a été construite dans .NET 4 de ce que je peux voir d'ildasme. De ma compréhension (bien que je ne l'ai jamais utilisée auparavant), FuslogVW affiche uniquement les journaux des exceptions de liaison de montage correctes? Tout est contraignant correctement éventuellement, il suffit de prendre Waaay à long terme.