Managing state

Always rely on SharePoint’s central store – the database. Don’t try and store data on the file system as you will never be sure which server has what copy. Use lists for data that should be exposed to administrators and users. Use SPPersistedObject or the patterns & practices Application Setting Manager for application configuration.

Caching

This is just another method of storing state, albeit one that’s faster (yet limited in resources)! Be aware when using ASP.NET caching that every server will cache your data separately in its own copy of RAM. These will get out of sync resulting in inconsistencies that you will need to handle. You may find AppFabric Caching as described by Wictor Wilén a good solution to this problem.

Thread safety

Never store rich objects that aren’t thread safe such as SPListItem in the cache or any other form of state. Aside from potentially taking up unnecessary space, these objects won’t work properly once deserialized. Introducing caching also opens up your application to potential threading issues, as explained in “Understanding the Potential Pitfalls of Thread Synchronization” in this best practices article. You don’t need to use System.Threading to be multithreading!

Testing

Even if you can’t develop in a load balanced environment, it really pays to test in one. A lot of situations just can’t be reproduced otherwise! I strongly recommend to ensure your production environment always closely matches test in configuration (even if number of servers is unreasonable).

Conclusion

In summary: always store data in the database to avoid problems with different servers accessing the same content and keep any caching simple and stateless. Oh, and be sure to thoroughly test!

Defining your own areas and categories

The out-of-the-box behaviour is fine, but it’s much nicer for both end user and developer to see the actual application name causing the exception, rather than the generic “Patterns and Practices”. No problem, you can define your own areas and categories! What does this mean? Examine a ULS log file and you’ll see at the top a series of column headers. “Area” is typically used for the a major piece of functionality or application name. “Category” is some component of that functionality. For logging to the Event Viewer, the Source column is used for “Area”, and “Category” is the first line of the log entry.

The many ILogger methods

Before continuing, let’s examine how we use a custom area and category when calling the ILogger. If you have a look at its interface, you’ll find several variations of two methods. LogToOperations writes to both the ULS trace log and the Event Viewer. TraceToDeveloper writes to the trace log only. Some variations allow you to specify a category and others don’t. At this point, you really want to look at the many options and narrow down the list to one or two that are going to be most useful to you. I generally only use the following depending on whether I’m logging exceptions or information:

void LogToOperations(Exception exception, int eventId, EventSeverity severity, string category);
void LogToOperations(string message, string category);

Notice the category parameter which is where we set both the area and category to use. The supplied string here needs to be of the format “Area/Category“. This is fairly distasteful in design and much like a “magic number“, but that’s the way the API has been written. I recommend creating a LoggingHelper class that abstracts this away and reduces the risk of making a mistake.

Registering the areas and categories

There is one last trick to perform before using these custom areas and categories. They must be provisioned as part of a farm level feature. This is primarily because updates are made to the SharePoint configuration database which requires execution by an account with farm level permissions. It’s also because registering new sources for the Event Viewer to use must be done by a user with permissions to write to the Windows registry. Executing this registration as a farm-level event receiver should alleviate these issues (unless you’re deploying to a locked down environment where you may have some problems).

There is sample code on how to register areas and categories in the SharePoint Guidance documentation. (There’s also plenty of other great stuff there about how the logger works and I recommend taking a few minutes to read it.) One extra thing to take note of if you plan on logging to the Event Viewer in a multi-server farm is that this registration needs to take place on each server in the farm. There are instructions on how to do this by lead SharePoint p&p developer Chris Keyser.

Segue – suggestions

As you would have gathered, this library is not perfect. Here’s some thoughts on gotchas and what I feel could be improved:

• The ILogger interface contains too many method signatures which causes confusion. Most developers will only settle on their chosen one or two. I’d like to see a simple entity-style class used for specifying logging parameters instead of the many options given.
• Using a ‘magic number’ style string format to select an area and category is error prone. Area and category should be separated, and preferably strongly typed.
• It’s clear to see the ILogger interface has been designed around logging to the ULS and Event Log. This makes it not as adaptable to other scenarios. Again, using an entity-style class for parameters would help make it more generic.
• To register your own custom areas and categories, a farm feature is required so that enough permissions are available to write to the Windows registry. In multi-server farms there is added complexity.

On the plus side, a lot of these issues only need to be resolved once.

Conclusion

I really like the logging functionality provided with the patterns & practices library. It’s generally easy to use and certainly powerful. There are some issues, but it’s a great way to get exposure to the benefits of this library and immediately reap rewards!

• Log to both the ULS trace logs and the Windows Event Viewer
• Define your own logging categories so they appear under your application’s name everywhere
• Support for logging from the sandbox via a provided proxy
• Configure log event throttling using the out-of-the-box Diagnostic Logging page in Central Administration
• Contextual information such as current URL and logged in user is automatically added to log entries
• Don’t worry about logging long messages or correlation IDs, it’s all handled for you
• Use the provided logging interface to easily write your own logger
• Service locator provided means almost no code changes when changing to a different logger (for a future blog post)

If you’re a developer that’s never used the library before, this post helps you dip your toes in the water and harness this logging power!

Getting started

The p&p release is a little confusing. There’s the CodePlex project, which links to various components and where you should ask for help or log any bugs you find. However the code is not kept there – download that from MS Downloads. You’ll want to keep an eye on this page for updates as they aren’t announced anywhere that I’ve found.

Once extracted to your development server, you need to build the library. Everything is open source apart from the service locator (for a later blog post). The solution to build can be found at Source\SharePoint 2010\Microsoft.Practices.SharePoint.sln.

Build this project, then copy the output Microsoft.Practices.ServiceLocation.dll and Microsoft.Practices.SharePoint.Common.dll to your project and reference them.

Log away!

Using the logger is pretty easy. First, add these using statements everywhere you wish to log:

using Microsoft.Practices.SharePoint.Common.Logging;
using Microsoft.Practices.SharePoint.Common.ServiceLocation;

Then declare the logger as a field and obtain a reference to it:

ILogger _logger = SharePointServiceLocator.GetCurrent().GetInstance<ILogger>();

Now let’s log an exception…

Exception ex = new ApplicationException("This is my test exception");
_logger.LogToOperations(ex);

…and see what appears in the ULS log…

09/08/2010 20:15:34.66 w3wp.exe (0x15D8) 0x0EF0 Patterns and Practices SharePoint Guidance 0000 Information Category: SharePoint Guidance: An exception has occurred. ExceptionType: ‘ApplicationException’ ExceptionMessage: ‘This is my test exception’ StackTrace: ” Source: ” TargetSite: ” Additional Information: Request TimeStamp: ’2010-09-08T20:15:33.2171690+09:30′ UserName: ‘AA\Administrator’ Request URL: ‘http://aasp2010dev:31000/default.aspx?PageView=Shared&InitialTabId=Ribbon.WebPartPage&VisibilityContext=WSSWebPartPage’ User Agent: ‘Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; InfoPath.3; .NET CLR 3.5.30729; .NET CLR 3.0.30729)’ Originating IP address: ’127.0.0.1′ 2cc97a55-1c4d-4e22-b145-4de9a3fdf6e1

…and Event Viewer:


Log Name: Application
Source: Patterns and Practices
Date: 8/09/2010 8:15:34 PM
Event ID: 0
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: aasp2010dev.aa.com
Description:
Category: SharePoint Guidance: An exception has occurred.
ExceptionType: 'ApplicationException'
ExceptionMessage: 'This is my test exception'
StackTrace: ''
Source: ''
TargetSite: ''

(many other details removed for brevity)


Here you can see the benefits these simple steps have already given – lots of context relating to exception to help diagnose the problem!

Logging – make it happen!

That’s it for now, but we’ll be exploring a lot more about this library in the next blog post. Remember – you owe it to yourself and your users to log appropriately. Ease the pain of bugs found in production code!

Download and references:

• SharePoint Guidance CodePlex Project
• SharePoint Guidance 2010 Download

Rewind to July 2009

I was recently given the task of deploying the Oracle Hyperion web part for testing in one of our SharePoint sites. There was no formal requirement for this, it was simply requested because there appears to be no documentation or information available on what functionality this mysterious web part can provide. What better way to find out than to deploy it for testing, right? There are even quite detailed instructions available!

Well stop right there, folks. In fact before you read any further, my recommendation is to run far, far away from this unusual piece of technology. Why? Well let’s start with the high-level changes you’ll need to make to your SharePoint environment:

• Add the web part itself
• Configure single sign-on (SSO) – makes sense as Oracle is an external product
• Create a ‘proxy page’ – a virtual IIS application inside your SharePoint application
• Install a custom HTTP handler
• Create a custom database

Hmmm… seems rather unusual so far (particularly that custom database – don’t we already have data stores in both SharePoint and Oracle?). But then read the fine print as it describes three best practice no-nos all on one page (that’s page 71 if you’re following along readers) without even so much as to explain what effect the changes will have.

1. Set the trust level to Full.
   Say goodbye to security in your SharePoint farm right here. With trust level set to Full, custom code can run without restriction and do whatever it likes. Really Bad Idea. Oracle, please look into Code Access Security.
2. Replace the default SQL Server session state provider for SharePoint.
   I’ll be honest. I have no idea what they are doing here or why. All I know is that the chances of support from Microsoft on such a fundamental change to how session state works in SharePoint has to be zero.
3. Comment out the PublishingHttpModule.
   Say goodbye to one of the best features in SharePoint – publishing pages. For yet another strange and unexplained reason, this has to go. Not sure if they put it back somewhere with their custom code, this isn’t mentioned.

Now follow through almost twenty pages, some with screenshots, to configure this nightmare, and that doesn’t included setting up SSO. I like to think I’m pretty good at puzzling out this sort of thing, but this baby has got me beat.

Things I found that might help others… Add the server hosting SharePoint to the Local Intranet zone in Internet Explorer security settings. Otherwise, you might encounter an “Invalid index” message while browsing the repository in Internet Explorer. Also, uninstall the Enhanced Security Configuration from Windows Server to prevent logon issues.

I wonder if anyone, anywhere has been able to successfully deploy this thing? More to the point, why did Oracle bother to even develop it?

When the discontinuation of the original Stack Exchange business model was announced, I felt plunged into the wilderness and lost motivation in the site for a little while. Suddenly, calling this community our own while running it on the awesome platform that powered sites such as Stack Overflow appeared impossible come April 13 2011. Stack Exchange 2.0 would be owned by the Stack Overflow team with input from the community (instead of owned by members of the community) and the closest alternative platform was (and still is) a long way behind in functionality and general awesomeness.

But in the interests of the fantastic community and content I wanted to see continue, I got over myself! I arranged with Nick Swan, the original SharePoint Overflow mastermind that we look at moving the platform to Stack Exchange 2.0. After eventually being able to contact the very busy Stack Exchange team, things were put into motion and here we are (87% committed at time of writing).

So what’s going to make SharePoint Overflow 2.0 so exciting?

Our site started using a copy of how Stack Overflow functioned back in mid-late 2009. Now, if you’ve ever read the Stack Exchange team blog, you’ll know they’ve added many new features since then. Some of these will be great for us! Here are my picks.

We’ll be exposed to a greater audience

Stack Exchange sites are promoted across the network. You can see this in ads for questions on other sites, Twitter feeds, the listings of Stack Exchange sites, they’re everywhere! One of the great things is that a single login to the Stack Exchange network associates accounts across sites. This boils down to it being easy for people to come and join us.

We could be the keepers of all existing SharePoint questions from the trilogy sites

As a community in association with Stack Exchange, we may decide that SharePoint Overflow is where all SharePoint questions should live. That means many questions from across the trilogy sites will be migrated, as well as any new questions. It also gives those questions about SharePoint that don’t seem to quite “fit” in one of the existing trilogy sites a home (great explanation by Stuart Pegg). This should make us the largest SharePoint community Q&A site outside of MSDN and TechNet!

Note: “trilogy” here means the sites Stack Overflow (programming), Server Fault (systems administration), and Super User (computer enthusiasts).

We’ll have more encouragement to accept answers

Something that’s always been a problem in our site has been encouraging people to accept answers (and vote generally). Complete speculation from me is that this isn’t a nice experience or have any obvious benefits on MSDN/TechNet, which is the platform most of our users are previously familiar with.

Reason aside, users will have an “accept rate” shown underneath their reputation on questions they ask, just like on my Stack Overflow question here. This feature made a big difference when it was introduced on the trilogy sites! Sadly we just missed out on it with Stack Exchange 1.0.

We’ll have our own meta site to discuss how the site should be run

I’ve really felt a bit in the dark with how to administer the site, and haven’t wanted to clutter it up with a lot of meta questions. (We used the sharepoint-overflow tag for this.) With our own meta site (example), it will be much easier for us all to discuss the future and do the best thing in the interests of our community.

We’ll have several interesting possibilities of support

The Stack Exchange team really actually care about supporting communities and making the Internet a better place. For example, they’ve recently announced community conference sponsorships to help people share knowledge and experiences. If they can do that, I think we might at least be able to get some stickers?!

The future is bright

So that’s my feelings on the exciting future of our site! These are exciting times, so please, come and join us! Here’s how to spread the word. (As explained by Tom Resing we most need committers to have at least 200 reputation on other Stack Exchange sites.)

Finally, a very sincere thank you to the fantastic members of the community that have helped us become so successful (notably moderators Marc Anderson and Charlie Lee)!

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.