2010-08-18 1 views
9

Lorsque j'exécute F # compilateur - fsc.exe - sur notre serveur de construction, il prend des âges (~ 20sec) pour fonctionner même s'il n'y a pas de fichiers d'entrée. Après enquête, j'ai découvert que c'est parce que l'application essaie d'accéder à crl.microsoft.com (probablement pour vérifier si certains certificats ne sont pas révoqués). Cependant, le compte sous lequel il s'exécute n'a pas accès à Internet. Et parce que nos routeurs/firewalls/quoi que ce soit laisse tomber les paquets SYN, fsc.exe essaie plusieurs fois avant d'abandonner.fsc.exe est très lent car il essaie d'accéder à crl.microsoft.com

La seule solution qui vient à l'esprit est de mettre clr.microsoft.com à 127.0.0.1 dans le fichier hosts mais c'est une solution plutôt désagréable. De plus, j'aurai besoin de fsc.exe sur notre boîte de production, où je ne peux pas faire de telles choses. D'autres idées?

Merci

Répondre

8

Venez à travers moi-même - voici quelques liens ... à de meilleures descriptions et des alternatives

http://www.eggheadcafe.com/software/aspnet/29381925/code-signing-performance-problems-with-certificate-revocation-chec.aspx

Je déterré cette forme un vieux MS KB pour Exchange lorsque nous avons atteint ... juste a le serveur DNS pour répondre comme il est dit (pourrait être la solution pour votre boîte de production.)

MS Support KBLa vérification CRL expire car elle ne reçoit jamais de réponse. Si un routeur devait envoyer un paquet ICMP ou une erreur similaire au lieu de en abandonnant simplement les paquets, le contrôle CRL échouerait immédiatement et le service commencerait. Vous pouvez ajouter une entrée à crl.microsoft.com dans le fichier hosts ou sur le serveur DNS et envoyer les paquets à un emplacement légitime sur le réseau, tel que 127.0.0.1, qui rejettera la connexion .. "

+1

Le dernier lien a aidé.J'ai ajouté fsc.exe.config comme conseillé là-bas et il a fait l'affaire.Solution toujours assez merdique, mais le meilleur jusqu'à présent.Merci – Elephantik