Build Delay after opening Windows Form designer
-
I have noticed that when working with VS 2008, there is sometimes a long (20-30 seconds) delay after building a project where VS hangs. The delay is not caused by the build because the output window shows that it is complete and all the assemblies are created. After some experimenting, I realized that this starts happening after opening a Windows Forms designer. Once I open the designer, all builds will have the delay until I restart VS. This happens even if I close the designer. I have searched for other people encountering this, but all have I found are complaints about the performance of the Web designer. Has anyone else experienced this problem? Do you know if there is a fix or work around?
-
I have noticed that when working with VS 2008, there is sometimes a long (20-30 seconds) delay after building a project where VS hangs. The delay is not caused by the build because the output window shows that it is complete and all the assemblies are created. After some experimenting, I realized that this starts happening after opening a Windows Forms designer. Once I open the designer, all builds will have the delay until I restart VS. This happens even if I close the designer. I have searched for other people encountering this, but all have I found are complaints about the performance of the Web designer. Has anyone else experienced this problem? Do you know if there is a fix or work around?
Hi, Is the system connected to the internet. If no, probably the reason why this problem is occurring is because of the mechanism used by the .NET Common Language Runtime (CLR) to verify code-signed .NET assemblies. Part of the verification process requires an online look-up to check whether the certificate with which the assembly is signed has been revoked and is no longer valid. Windows does this by downloading a CRL (Certificate Revocation List). The first time a code-signed assembly is loaded by the .NET CLR, the CRL is downloaded from the certificate provider's server and cached on the system. Hope this helps.
Vinay ComponentOne LLC. www.componentone.com
-
Hi, Is the system connected to the internet. If no, probably the reason why this problem is occurring is because of the mechanism used by the .NET Common Language Runtime (CLR) to verify code-signed .NET assemblies. Part of the verification process requires an online look-up to check whether the certificate with which the assembly is signed has been revoked and is no longer valid. Windows does this by downloading a CRL (Certificate Revocation List). The first time a code-signed assembly is loaded by the .NET CLR, the CRL is downloaded from the certificate provider's server and cached on the system. Hope this helps.
Vinay ComponentOne LLC. www.componentone.com
My system is connected to the internet. During this delay VS takes 100% processor, so I don't think the delay is related to waiting on the network.
-
My system is connected to the internet. During this delay VS takes 100% processor, so I don't think the delay is related to waiting on the network.
Hi, When the .NET CLR loads a code-signed assembly and is unable to reach the CRL distribution point, it records the failure as an inability to provide the assembly evidence that it was code-signed. So the assembly is allowed to load, but is not marked as being digitally signed. There is a 15-20 second delay for CRL retrievals. This is how long the CLR will keep on re-trying to download the CRL before it finally times out. So the delay in loading the .NET assembly occurs because Windows is unable to download the CRL and keeps trying to download it for 15-20 seconds before timing out. Complex applications have hundreds of these assemblies so the time delay can be quite noticeable. In case a machine does not have internet connectivity, the delay time can increase. Hope this helps.
Vinay ComponentOne LLC. www.componentone.com
-
Hi, When the .NET CLR loads a code-signed assembly and is unable to reach the CRL distribution point, it records the failure as an inability to provide the assembly evidence that it was code-signed. So the assembly is allowed to load, but is not marked as being digitally signed. There is a 15-20 second delay for CRL retrievals. This is how long the CLR will keep on re-trying to download the CRL before it finally times out. So the delay in loading the .NET assembly occurs because Windows is unable to download the CRL and keeps trying to download it for 15-20 seconds before timing out. Complex applications have hundreds of these assemblies so the time delay can be quite noticeable. In case a machine does not have internet connectivity, the delay time can increase. Hope this helps.
Vinay ComponentOne LLC. www.componentone.com
How can I check if my machine is unable to reach the CRL distribution point? (and why would this only happen after I open a Windows Form Designer?)
-
How can I check if my machine is unable to reach the CRL distribution point? (and why would this only happen after I open a Windows Form Designer?)
Do you have a personal firewall, or is windows firewall enabled? If so, check it's options to see if there's an application blacklist. It's possible that the first time the program tried to reach teh internet, it popped up a dialog and you answered to disallow it (possibly not even realizing what you were doing). it's also possible that, by default, the access is being disallowed. But you should be able to allow it again. I can't give specifics because I don't know the exact situation, but if a local firewall software component is blocking access to the internet, this would have the same symptoms as not being connected to the internet (for that application). Again, I'm presuming, but it's possible that it only happens after the form designer is open because it's a visual control that's cuasing the check to take place. Another place to look would be if you have any custom controls that access the internet for updates or authentication. (Again, the firewall issue could be at work.) Just thoughts, inspired by the earlier posts. Good luck!