Add the following line to your ASPNET.CONFIG or APP.CONFIG file:
<?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <generatePublisherEvidence enabled="false"/> </runtime> </configuration>
Note the ASPNET.CONFIG file is located in Framework Directory for the version of the Framework you are using. For example for a 64-bit ASP.NET application it would be:
c:\Windows\Microsoft.NET\Framework64\v2.0.50727
For a 32-bit application it would be:
c:\Windows\Microsoft.NET\Framework\v2.0.50727
I have seen this a bunch of times while onsite. The problem goes something like this:
When I restart my ASP.NET application the initial page load is very slow. Sometimes upwards of 30+ seconds.
Many people just blame this on “.NET Startup” costs but there is no out of the box reason that an ASP.NET application should take that long to load. Some applications do work on startup which can cause a startup slow down but there are other things that cause slow downs. A common cause that I have seen often recently is Certificate Revocation List (CRL) checking when generating Publisher Evidence for Code Access Security (CAS).
A little background – CAS is feature in .NET that allows you to have more granular control over what code can execute in your process. Basically there are 3 parts:
So when a module loads it presents a bunch of evidence to the CLR and the CLR validates it. One type of evidence is the “publisher” of the module. This evidence is validated by looking at the Authenticode signature which involves a Certificate. When validating the Certificate the OS walks the chain of Certificates and tries to download the Certificate Revocation List from a server on the internet. This is where the slowdown occurs.
A lot of servers do not have access to make calls out to internet. It is either explicitly blocked, the server might be on a secure network, or a proxy server might require credentials to gain access to the internet. If the DNS/network returns quickly with a failure the OS check will move on but if the DNS/network is slow or does not respond at all to the request we have to timeout.
This can occur for multiple modules because we create this evidence for each module that is loaded. However if we have looked for a CRL and failed we will not recheck. However different certificates have different CRLs. For instance a VeriSign Certificate may have one CRL URL but a Microsoft Certificate will have a different one.
Since this probe can slow things down it is best to just avoid the probe if you do not need it. For .NET the only reason you would need it is if you are setting Code Access Security based on the module Publisher. Because this can cause potential slow downs and you do not need to occur this penalty you can just disable the generation of the Publisher Evidence when your module is loaded. To disable this use the <generatePublisherEvidence> Application configuration. Just set the enabled property to false and you will avoid all of this.
Now for ASP.NET applications it was not immediately obvious how to do this but it turns out that you cannot add this to an applications Web.Config but you can add it to the ASPNET.CONFIG file in the Framework directory. For other applications just add the attribute to the APP.CONFIG file.
In closing there are several blog entries that do a great job of demonstrating how this will show up in the debugger and other details on CRL issues and workarounds:
We are highlighting this as the first in a series of general best practice recommendations.
NOTE – If you have .NET 2.0 RTM you will need this hotfix - http://support.microsoft.com/default.aspx/kb/936707
The PFE Dev team would like to welcome Micheal Learned to the blog. Here is a bit about Mike:
My name Is Micheal Learned, and I’ve been working for Microsoft for over a year now with some of our Premier customers across the US, and helping them support a variety of .NET related systems and tools. I’m doing a lot of work currently with VSTS/TFS 2008, and helping customers get up and running with new installations, migrations, and general knowledge sharing around this product. I also enjoy working with web applications, IIS, and just researching various new Microsoft related technologies in general. In my free time I enjoy sports (I watch now, use to like to play), and spending time with my son Nicholas (7), and daughter Katelyn (3), and generally just letting them wear me down playing various kids stuff.
Enough about here is the good stuff:
I’ve been spending a lot of time recently working with customers on TFS and VSTS 2008. Some of my customers have required some support around getting a clean install, or troubleshooting some post-install issues, so I thought I would post a few of the common issues I’ve been seeing.
First of all, for any pre-install or post-install issues, I highly recommend you run the TFS Best Practices Analyzer, which is available as a “power tool” download here.
The analyzer can run a system test, and generate a report indicating the health of your existing system, or a report identifying possible issues with your environment configuration ahead of a TFS installation (pre-install). The information is useful, and generates links to help files that can help you solve various issues. It helped me through a range of issues while troubleshooting an installation recently, including IIS permissions, registry information, etc. The idea is that more and more data collection and reporting points are being added to this tool, so you should keep an eye out for future releases of the tool as well.
Before doing any new installation it is imperative you download the latest version of the TFS 2008 installation guide available here. I can’t overstate the importance of following the guide step by step with any new installation, and although this version of TFS is a smoother install than the previous version (2005), it is still important you pay close attention to setting up the proper accounts and their perspective network permissions. It may seem a little cumbersome, but you’ll want the TFS services, and various accounts running with the least sufficient permissions as a security best practice, and it is well documented in the guide.
Enough about general stuff, let’s discuss some specific points:
“Red X of Death”
If after installation, you’re client machines are seeing a red “X” on either their documents or reports folders in Team Explorer, then they are encountering a permissions issue on SharePoint (if documents folder), or the Reporting Services layer (if reports folder). I’ve seen this to be quite common, and it should just be pointed out that you should configure proper permissions for your Active Directory users at each of those tiers. Visual Studio Magazine Online has a nice article documenting this here http://visualstudiomagazine.com/columns/article.aspx?editorialsid=2742 .
“Firewall Ports”
If you are running TFS, and have a firewall in play, you will need specific ports for the various TFS components to communicate properly. The ports are well documented in the TFS guide under the “Security Issues for Team Foundation Server” section, and there is some automation with new installations that will configure your windows firewall ports for you during install. If you need to configure them post-install, it is just a matter of setting up the firewall exceptions manually.
“TFS Security
TFS security is deserved of its own blog entry, but I want to just mention a few quick items since TFS security can be a common stumbling block initially. The TFSSetup account (as described in the TFS guide) is by default an administrator on the TFS server. You’ll need to configure permissions on several tiers for TFS for your other users and groups. Specifically configure permissions at the overall TFS server level, TFS project level, Reporting Services level, and SharePoint level. It may seem cumbersome at first, but just right click your server node in Team Explorer, and it becomes a point and click exercise. Right click the project node to configure project level permissions. As a best practice for manageability scenarios you will want to simply use Active Directory Groups to drive this, and if you have a need, you can get very granular for setting up permission, new roles, etc. Also there is a power toy available that gives you a singular GUI view for managing permissions all in one place that you can download here http://www.codeplex.com/Wiki/View.aspx?ProjectName=TFSAdmin .
“Just remember TFS is multi-tier”
Finally I would just point out to keep in mind that TFS 2008 is a distributed system with multiple tiers. Open IIS or SQL Server to poke around and look at the databases, directories, permissions, etc to familiarize your-self with the architecture (Do not directly edit the database – Look, don’t touch!).
Many customers of course are often “viewing” their TFS server from Visual Studio, and if you see issues with connecting to a TFS project, connecting to a TFS server, or having issues with the various views on top of reports or SharePoint documents, you should initially keep in mind that the underlying reasons probably lie on a IIS site being down, SharePoint configuration, an improper permission, or a firewall port, etc. In a nutshell, focus on permissions and configuration settings at each tier, per the TFS install guide, and your issues are likely to be solved!
Mike Learned --Premier Field Engineer .NET
Starting back in Windows 2000, if I recall correctly, the OS added a feature to try and handle unresponsive windows. The idea is that if an application hangs we do not want the window that is associated with that application to block other stuff that the user is trying to do. This feature has been improved through Windows XP and now into Vista. The feature is not pretty good.
When the OS detects that the application is not “responding” to messages it will take control of y
I came across this when working with a customer that has a client side application. It is single threaded for the most part and has a work flow like this:
This is not an uncommon scenario especially for application that have been around for a while. Sometimes it can be very hard to allow the window to paint during some long running applications and while allowing painting is the real answer there are times where this is MUCH easier said than done.
The feature that grays out windows seems to have gotten more aggressive in Windows Vista to better detect various hang scenarios. This is why this became an issue for them. Basically it was becoming more common to see the graying or “ghosting” of the application’s window. This lead to users thinking the application was dead (the status bar also gets grayed out) and terminating the application. In XP the application would stay there and while the main part of the UI would not respond you could still watch the status bar move.
The question though became what do we do about this? The obvious answer is make the application responsive during the long running application. While this is a goal there is no short term way to do this. We tried a bit to pump more messages but run into a sticky issue – How do I “appear” responsive without actually being responsive. We were basically trying to guess what the OS was looking for and since this can change, as we have seen, this is not reliable.
After some digging I found an interesting API:
DisableProcessWindowGhosting http://msdn.microsoft.com/en-us/library/ms648415.aspx
Basically this API tells the OS to skip the ghosting even it detects the application as unresponsive. This API will take effect for the run of the application.
The real answer is to fix the application to be responsive as mentioned but that is not always easy so this is a stop gap.
Side note is that when you debug an application the graying or ghosting of the window will not occur. So if you are trying to reproduce make sure that you are running outside of the debugger (this got me when trying to reproduce!)
Hope this helps and have a great weekend!
Zach