Resolve 500 Internal Server Errors

If you receive a 500 (Internal Server Error) when running an application in IIS (SharePoint or otherwise), what can you do to resolve it? The ULS logs won’t show anything because the error happens before SharePoint or your web application has a chance to log an error. However, IIS has its own trace logging which can be easily turned on.

1. Open IIS and click on the node for the site returning the error
2. In the Actions pane on the right, click Failed Request Tracing…
   
3. Check Enable
   
4. In the center pane, click the Failed Request Tracing Rules icon
5. In the Actions pane on the right, click Add…
   
6. In the wizard that opens, click next to select all content
7. Then check Status codes(s) and enter 500, or any other error codes you want to trace
   
8. Click Next to select all trace providers, and the Finished
9. You will now see logs get created for failed request in the following folder:C:\inetpub\logs\FailedReqLogFiles
10. Clicking on one of the log files will display the following information. In this case we had a duplicate handler <add> element in the web.config – very easy to diagnose and correct with tracing enabled!
    

Deleting TFS Work Items

When setting up team projects in TFS sometimes it’s helpful to create a few test issues or bugs to make sure any customizations you have made function correctly. However, you will quickly notice there is no option to delete these work items from the UI or administrative console. It can be done though via the Command Prompt. Here’s how:

1. Open a Visual Studio Command Prompt window
   
2. Enter the following command:
   witadmin destroywi /collection:<team project collection URL> /id:<work item id>
   

For more information on using the Work Item Type Administration console utility see: http://msdn.microsoft.com/en-us/library/dd312129.aspx

Permission Work Item Types in TFS

When tracking work items for a development project you may want to capture issues reported by business users. However, giving business users access to TFS can lead to a lot of bugs getting reported that are really just issues that need to be triaged, broken down, or better categorized. One issue may be resolved by fixing 3 different bugs, 2 tasks being performed, and perhaps a test case developed. An issue can then be turned into a bug once the development team has reviewed it, or several different types of work items and related back to the original issue. But how can we ensure business users only enter issues, not bugs?

You might think work item types can be assigned permissions by user or groups. However, TFS currently doesn’t support this. There is a way though to still prevent a group of users from creating work items by type.

1. Create a global group for business users and add them as members:
   

   

2. Install the TFS Power Tools for VS if you haven’t already.
   http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f
3. The Power Tools install the Process Editor which allows you to edit work item types. Open each WIT for your project and go to the workflow tab:
   
4. Select the first transition and set Not to the business user group you just created. The prevents the first workflow step from executing if the current user is in the group.
   
5. Now users in the business group cannot save work items of type Bug:
   

Of course, this approach merely prevents users from creating work item types they don’t have access to. We still need to train business users to enter issues into TFS since the error message is not very informative. And of course security trimming would be nice but at least we have the bare minimum of access control by item type.

October CU Fails to Install

After you install SharePoint cumulative updates you need to run the SharePoint 2010 Products Configuration Wizard (psconfig.exe). However, while installing the October 2011 cumulative update recently, I found it was failing on the last step where the udpate gets applied. I discovered that the SharePoint 2010 Timer service was getting shut down after the first step when running psconfig which in turn made the last step fail. The solution is simple: keep the Services console open when running psconfig and restart the Timer service before reaching the last step!

IIS Timeout When Debugging in VS

You can stop the Visual Studio debugger from timing out and stopping by changing a single setting in IIS. Just select the application pools you want and go to Advanced Settings in the IIS Manager.

There you can set the Ping Enabled property to False which will keep the debugger alive indefinitely.

You should also do this for the service application pool as well so things like the profile service don’t time out. Since it’s identified by a GUID you need right-click and View Applications to find the right pool.

jQuery Selectors with Server-Side ID’s

If you want to bind a client-side function to an ASP.NET control using a jQuery selector you can use the attribute selector id$= to specify what the client id ends with. The leading underscore is added to match only complete server id’s.

Take an ASP.NET control:

Which gets rendered with the following id:

We can bind an event handler in jQuery using the following selector:

This is a handy way to wire up client-side functionality to your server-side ASP.NET controls.

Deployment Conflict Resolution in Visual Studio

If you are provisioning a ListInstance in Visual Studio you may see the following error message:

The URL or name of this list instance conflicts with a list instance already on the server.
The list instance on the server will be deleted before deploying the new list instance.

If you select Resolve Automatically, your list and all of its data will be removed before a new instance of the list is provisioned. To prevent this, you can set the Deployment Conflict Resolution property of the list instance in the Solution Explorer to None. Simply right-click on the list instance project item in VS and select Properties. Then select None from the dropdown list of values: