2010-08-18 11 views
9

Quando eseguo F # compiler - fsc.exe - sul nostro server di build ci vogliono secoli (~ 20sec) per funzionare anche quando non ci sono file di input. Dopo alcune indagini ho scoperto che è perché l'applicazione tenta di accedere a crl.microsoft.com (probabilmente per verificare se alcuni certificati non vengono revocati). Tuttavia, l'account con cui viene eseguito non ha accesso a Internet. E poiché i nostri router/firewall/qualsiasi cosa appena rilasciano i pacchetti SYN, fsc.exe prova diverse volte prima di mollare.fsc.exe è molto lento perché tenta di accedere a crl.microsoft.com

L'unica soluzione che viene in mente è impostare clr.microsoft.com su 127.0.0.1 nel file hosts ma è una soluzione piuttosto sgradevole. Inoltre, avrò bisogno di fsc.exe sulla nostra scatola di produzione, dove non posso fare cose del genere. Altre idee?

Grazie

risposta

8

imbatto in questo io stesso - ecco alcuni link ... alle descrizioni migliori e alcune alternative

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

ho scavato questa forma un vecchio MS KB per Exchange quando colpiamo esso ... Appena ricevuto il server DNS di rispondere come ha dichiarato (potrebbe essere la soluzione per la vostra casella di produzione.)

MS Support KB

Il controllo CRL è scaduto perché non riceve mai una risposta . Se un router inviava un pacchetto ICMP o un errore simile invece di , il pacchetto CRL falliva immediatamente e il servizio si avviava. È possibile aggiungere una voce a crl.microsoft.com nel file host o sul server DNS e inviare i pacchetti a una posizione legittima nella rete, ad esempio 127.0.0.1, che rifiuterà la connessione .. . "

+1

L'ultimo collegamento ha aiutato. Ho aggiunto fsc.exe.config come consigliato e ha fatto il trucco. Ancora una soluzione piuttosto schifosa, ma la migliore finora. – Elephantik