How can we help you today? How can we help you today?
dany
Hi, I just had a similar problem with another Assembly in a .NET project and now find the same with Reflector. The EXE is signed with a certificate which tries to validate itself via the Internet. In case of Reflector it lasts around 90 seconds and tries to contact crl.thawte.com, which is probably in most cases not possible due to closed net or FireWalls (use WireShark for proof, here it is an amount of 30 DNS requests with 7 failure responses from our server, more or less). If an application has multiple assemblies (or DLLs) which are code signed as well, the DNS timeout is probably used for every file... This is an OS automated process to check the validity of the certificate! Just try to display the details of the code signature by opening the EXEs settings dialog and go to the digital signatures tab. Here select the signature and show the details. It lasts a while and displays them. Here you can see in the certificate details, that there is an URL of crl.thawte.com. If the DNS request is not declined (just ignored), it takes normally a 10 to 15 seconds (!) timeout. To prevent this validation, you can remove the tick at the 'Check for publisher's certificate revocation' in the extended Internet configuration (system control), but be aware that this is a global setting :!: :x. See also here: http://www.tech-archive.net/Archive/Office/microsoft.public.office.developer.com.add_ins/2007-08/msg00057.html IMHO I find this technique 'questionable' at best. Luckily the creator of the other component (for charting) agreed to present both a signed and an unsigned version. / comments
Hi, I just had a similar problem with another Assembly in a .NET project and now find the same with Reflector. The EXE is signed with a certificate which tries to validate itself via the Internet. ...
0 votes