The tool was released by Microsoft in early 2009 to help developers check for memory leaks in their code. However there’s no reason why an administrator can’t do the same. Memory leaks can cause performance problems and general instability in your SharePoint farm. This tool tells you of any potential problems, and here’s how to use it:

1. Download SPDisposeCheck and install. By default this will copy SPDisposeCheck.exe to C:\Program Files\Microsoft\SharePoint Dispose Check.
2. Examine the deployment file you have been given. If this is a WSP file, rename its extension to CAB and extract all DLL files. SPDisposeCheck also works on EXE files if you’ve been asked to run a console application.
3. For each DLL or EXE, run SPDisposeCheck using the filename as a parameter. To be assured of no SharePoint memory leaks, check that the “Total Found” line is 0.

Here’s an example that shows a potential leak:

If the tool finds some issues then you should query this with the developers. However as the tool itself states, this doesn’t necessarily mean there is a leak! Unfortunately it can report false positives depending on how the code has been written. Regardless, make sure you have an assurance that the tool is run as part of their release process and any flagged issues have been checked. The tool will never miss a problem with a false negative.

It’s as simple as that. Be sure to add SPDisposeCheck to your admin toolkit and don’t let those developers get away with dodgy code!

Hence, I created the SPQueryDemo web part! It tests and displays results from the following types of queries:

• For loop
• GetListItems from Lists web service
• SPQuery for SPList objects
• SPSiteDataQuery for cross-site list queries
• CrossListQueryInfo for cached cross-site list queries
• PortalSiteMapProvider for SharePoint Server publishing sites only

Download it from CodePlex.

I’ve also used this project to try out using user controls for output rather than the traditional dynamic creation of controls in a SharePoint web part. This has been attempted with an MVP-style pattern which I’d really appreciate any feedback on.

In the future I’d like to add more functionality, particularly for different query options and types of queries. There is also an annoying bug when changing the query type where the page needs to be refreshed before changes take affect. If anyone would like to help or just check out the code, please download the source and hack away! You can also contact me via this blog post or via Twitter.

Scenario

• “Require Check Out” is set to Yes (toggle the screenshot below in your mind, please!)
  
• Alert created to only send when new items are added
  

Problem

User does not receive alerts on new items.

What’s happening?

When “Require Check Out” is enabled, alerts for a new document are only processed when it is checked in, and only the most recent alert event is kept. Here’s a simplified version of what SharePoint is doing behind the scenes when a user sets an alert for new items only:

This is also an issue for users opting to receive alerts with the “All changes” or “Existing items are modified” options set. Their alerts will read the item has changed when actually it is new.

I asked about this on the SharePoint forums and received a good response from Lu Zou-MSFT confirming this behaviour. Unfortunately it’s unknown if this behaviour will change for SharePoint 2010.

They wanted all of their existing links list to be changed over to use this view. What makes this case more unusual is that this is actually the view displayed as “<Summary view>” in the web UI:

After much fighting with the SPViewCollection on the list, I discovered this post on Ketul Patel’s blog. He showed that to get a reference to this ‘hidden’ view, it is necessary to use the mouthy method SPList.GetUncustomizedViewFromBaseViewId(). The list view web part can then be changed to use the markup for the summary view. (Note that the web part needs to be re-added to the page so that the changes take effect correctly.) Here is a method that does this all this:

public static ListViewWebPart ReplaceWithBaseView(
	ListViewWebPart listViewWebPart, SPList list,
	int baseViewId, SPLimitedWebPartManager limitedWebPartManager)
{
	string zoneID = listViewWebPart.ZoneID;
	int zoneIndex = listViewWebPart.ZoneIndex;

	SPView view = list.GetUncustomizedViewByBaseViewId(baseViewId);

	ListViewWebPart replacementWebPart = new ListViewWebPart
	{
		Title = listViewWebPart.Title,
		ListName = listViewWebPart.ListName,
		Hidden = false,
		FilterString = listViewWebPart.FilterString,
		SuppressWebPartChrome = listViewWebPart.SuppressWebPartChrome,
		ViewContentTypeId = listViewWebPart.ViewContentTypeId,
		ListViewXml = view.HtmlSchemaXml,
		ExportMode = listViewWebPart.ExportMode
	};

	limitedWebPartManager.DeleteWebPart(listViewWebPart);
	limitedWebPartManager.AddWebPart(replacementWebPart, zoneID, zoneIndex);

	return replacementWebPart;
}

In order to call the above method, it’s simply a matter of getting a reference to the web part page and the web part. The magic number for “<Summary view>” is 0. Here is the calling code:

SPList usefulLinksList = web.Lists["Useful Links"];
using (SPLimitedWebPartManager webPartManager =
		web.GetLimitedWebPartManager("default.aspx", PersonalizationScope.Shared))
{
	try
	{
		foreach (WebPart webPart in webPartManager.WebParts)
		{
			if (webPart.Title == "Useful Links")
			{
				ListViewWebPart listViewWebPart = (ListViewWebPart)webPart;
				ReplaceWithBaseView(listViewWebPart, usefulLinksList, 0, webPartManager);
				break;
			}
		}
	}
	finally
	{
		webPartManager.Web.Dispose();
	}
}

Please wait while Explorer View is loaded. If Explorer View does not appear, your browser may not support it.

Searching around, the main reasons seem to be:

1. SharePoint site behind SSL – no fix at time of writing
2. IE security level changes – fixable by adjusting security levels or adding SharePoint site to Trusted Sites zone
3. WebClient service not running – fixable by starting this Windows service and ensure it is set to start automatically

For me the problem was #3, however attempts to start WebClient resulted in “File not found”-type errors. The following error was logged in the Event Viewer:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{BA126AD1-2166-11D1-B1D0-00805FC1270E}
to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool.

This familiar problem usually occursin SharePoint installations with the IIS WAMREG admin Service in Component Services. However this time searching the registry for the GUID in the error I had came up with the “Network Connection Manager Class”. Then searching for the GUID in its AppID key of {27AF75ED-20D9-11D1-B1CE-00805FC1270E} resulted in the netman component.

I then configured the security as described by the error in Component Services:

After stopping and restarting MS DTC I was able to start WebClient successfully and Explorer View worked again.

If that’s the case, the reason is probably file locking, most likely to occur if you have assemblies that need to be deployed to the Global Assembly Cache (GAC). If you ever find yourself in this situation, download a copy of the excellent Process Explorer tool, and follow these steps to verify:

1. Start Process Explorer on the server affected.
2. Press Ctrl+F, or in the menu click Find, Find Handle or DLL…, or just click the binoculars icon on the toolbar:
3. Type the name of the assembly DLL and click Search.
4. Under the Handle or DLL column, look for any assemblies located in the path C:\WINDOWS\assembly\temp. These lines tell you what process is locking the assembly.

OWSTIMER.EXE is the culprit!

The C:\WINDOWS\assembly\temp folder is Windows’ equivalent of “assembly purgatory” where the assembly will sit until Windows can deploy it. If the currently deployed assembly cannot be overwritten as it is already locked by a process then the DLL will stay there until the process releases the lock or ends, or until Windows is restarted (also ending the process).

One example where this problem can occur is when a WSP solution containing custom e-mail event receivers is upgraded. The timer service, OWSTIMER.EXE, executes event receivers via the Windows SharePoint Services Incoming E-Mail job. As the OWSTIMER.EXE process isn’t restarted when a solution is deployed, it will always hold onto the lock for the DLL containing the event receivers. The solution is to restart the Windows SharePoint Services Timer service on each web front end server. If you’re finding this problem in development, WSPBuilder v1.06 adds a “Recycle the Windows SharePoint Services Timer” option.

This problem can also occur when using Visual Studio if certain combinations of add-ins are installed. You can again check this by using Process Explorer and verify if DEVENV.EXE is the locking process. If so, take a good look at the add-ins you actually need. Regularly restarting Visual Studio is very frustrating and will severely cut your productivity!

Weirdness #1: Error 0×80630005. Verify this account has sufficient permissions and try again.

Resolution: Log in to the server as the “Microsoft Single Sign-on Service” service account. As described by Frank Grossmann.

Weirdness #2: Error 0×8063064a. Verify this account has sufficient permissions and try again.

Resolution: Remote desktop to the server’s console (i.e. use mstsc /console) or physically log in to the server. As described by Dave Sobel. The Microsoft documentation for configuring SSO implies this but is not explicit:

Note that you must be logged into the SharePoint Central Administration Web site on a farm server to configure single sign-on (SSO) for Office SharePoint Server 2007. If you attempt to configure SSO on a workstation or any computer that is not a farm server, you will see an error message that reads “Single sign-on cannot be configured from this server. To configure single sign-on, go to the computer running the single sign-on service and specify these settings locally.”

I haven’t finished the configuration yet but hopefully there won’t be more problems. The best guide I’ve found is MOSS Single Sign On Setup Step-By-Step and beats what Microsoft provides.

When doing the paste, the following error appeared:

The rows you modified could not be saved to the server due to validation errors. This is usually caused by invalid default values.

The error gives some clue as to the problem. I then attempted to add a single entry manually (without the paste) and received a new error:

Columns that require data are not included in this view. If you want to edit rows that are missing data in these columns, or add new rows, you must first add the required columns to the view.

Finally, I added all of the columns to the view and at last found the column causing the problem:

You must specify a non-blank value for Title.

Setting the Title field to not be required fixed the issue!

This first version is designed for a topology where each segment of the URL has its siblings in common. For example, Industry > Brand > Product or Division > Sector > Department. Depending on feedback I might make this more flexible.

Speaking of feedback, I’d really appreciate any comments from end users or other developers on desired features or comments on code WTFs! Please go to SPExcelator on Codeplex, download and add to the discussion!

Finally, special thanks to Robin Meuré for suggesting use of the excellent Excel Data Reader project.

We’ve looked at the problems with this feature, so what can we do about it? Well the new Project Server 2007 eventing model isn’t broken, so if you have a developer handy use that!

First, uncheck the Workspace Permissions box in Server Settings / Project Workspace Provisioning Settings. Then, have a look at the WssInterop event WssWorkspaceCreated. This fires whenever, um, a workspace is created. The initial state of a created workspace is with permission inheritance broken and the service account assigned to the workspace with Full Control.

From here, use SPWeb.EnsureUser for each user you’d like to give access to the workspace. This works by adding the user to the SPWeb if they haven’t been already. This does not give the added users any permissions to the workspace. SPWeb.EnsureUser also works with Active Directory groups, so a model where every user needs read access can be simply accomplished. Finally, use SPWeb.RoleAssignments, SPWeb.RoleDefinitions, and SPRoleAssignment.RoleDefinitionBindings to assign users the correct permissions (sorry, hopelessly glossed over but there are examples out there on how to use these).

Something else to note about a custom solution is that despite unchecking the Workspace Permissions box earlier on, Project Server’s behaviour does not change when giving access to the PWA site. It will still handle this for you according to the rules in Part 1, leaving you to configure the permissions for the workspace with custom code.

This works fine and if you are able to make use of Active Directory groups, is fast as well. Plus now that you’ve gone custom, you have all of the freedom (and traps) of flexibility and the ability to create your own permission assignment rules. Don’t forget you’ll need to invest time in creating custom administration pages to manage those as well.

So what about going forward and sticking with the product for a solution? For Project Server 14 or 2009 or 2010 I have no idea if there will be any changes to the workspace permissions functionality. If you agree that this feature needs looking at, please give feedback to the Project Server team as they do read it and listen (I’ve had great responses from Treb Gatte and Brian Smith on other issues). Hopefully bugs will be fixed and the feature improved next release!

Thanks for reading and I hope this helps someone else out there with similar experiences.