In a previous post, I wrote about a few gotchas that you may come across when doing event handlers in SharePoint. After writing that one, I’ve come across a few more. These are related to number fields.

Gotcha number one, which is not that weird actually, but is good to know about, is that number columns are always stored as doubles. I had a column defined to include numbers from 0 and up, with zero decimals. The error occurred in my event handler, when I tried to do int.Parse(properties.AfterProperties[<field name>].ToString()). This failed miserably. When inspecting the actual result of the .ToString(), it turned out to be “1.000000000000”, and not “1”, as expected.

Gotcha number two, which is a bit stranger, turned up after I had found out about gotcha number one. Both properties.AfterProperties[<field name>] and properties.ListItem[<field name>] return objects, BUT the underlying type for the AfterProperties is string, while the ListItem properties are the real type, in this case double. So, the properties.ListItem[<field name>] could be cast directly to a double, while the properties.AfterProperties[<field name>] had to go through a double.Parse(properties.AfterProperties[<field name>] .ToString()).

Well, that’s it for now. I have a few more “gotcha”-posts, and a couple of “did you know that”-posts waiting to be written, so stay tuned.

When using the SharePoint object model, it is important to properly dispose of instantiated objects of certain classes to avoid memory leaks. The most common objects that need to be disposed are SPSite and SPWeb. However, there are certain situations where it is not obvious that an instance is even created.

The SharePoint Dispose Checker Tool checks your assemblies against the dispose patterns listed in Roger Lamb’s SharePoint Developer Blog to check whether any of the patterns are in your code without being disposed.

The tool is run from the command prompt with your assembly as argument, or alternatively, a path to a folder containing several assemblies. If the PDB-files are in the same folder, the output will include additional source information about the problems detected.

Check it out at http://code.msdn.microsoft.com/SPDisposeCheck

When developing using the SharePoint object model, certain operations has to be run with elevated privileges. For instance, setting information into the property bag of a site needs to be done with elevated privileges. This post shows how this is done, and also includes a helper method for making it easier and shorter to do this.

There is a method called SPSecurity.RunWithElevatedPrivileges in the object model that takes a delegate as argument. The delegate is then run with more permissions. An important note regarding this: You must not use old references to SPWeb or SPSite instances inside your delegate, since they are “contaminated” with lower permissions. What you have to do is to create new SPSite and SPWeb instances using the Ids of the sites and webs you already have a reference to, like this:

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    using (SPSite site = new SPSite(SPContext.Current.Site.ID))
    {
        using (SPWeb elevatedWeb = site.OpenWeb(webId))
        {
            //Your code here
        }
    }
});

If you need to do these kind of operations in several locations, this is a lot of repeating code to include. A colleague of mine made a small helper method that does the setup for elevated privileges for you. Here’s the short code snippet:

private delegate void CodeToRunElevated(SPWeb elevatedWeb);
private static void RunElevated(Guid webId, CodeToRunElevated secureCode)
{
    SPSecurity.RunWithElevatedPrivileges(delegate()
    {
        using (SPSite site = new SPSite(SPContext.Current.Site.ID))
        {
            using (SPWeb elevatedWeb = site.OpenWeb(webId))
            {
               secureCode(elevatedWeb);
            }
        }
    });
}

To invoke this, you call on the method with the Id of your web as one argument, and a delegate taking an SPWeb as the other. When the method is invoked, the SPWeb argument will be “uncontaminated” and pushed to elevated privileges. This example sets the name, title, and description of a site.

RunElevated(web.ID, delegate(SPWeb elevatedWeb)
{
    elevatedWeb.Name = siteTitle;
    elevatedWeb.Title = siteTitle;
    elevatedWeb.Description = siteDescription;
    elevatedWeb.Update();
});

In a previous SharePoint project, I implemented a few event handlers that get called whenever an item in a list gets changed (or added/deleted). There were a few problems along the way that took a bit of searching before I found solutions. This post documents a few of the things that are good to know.

Read More

When creating custom webparts or other custom features in SharePoint that retrieves data from a SQL server, there are a few gotchas and pitfalls that you should be aware of. I spent a few hours battling a couple of problems, so I thought I’d document the things I found out here to spread the knowledge.

Read More

When declaring a feature, you can add an <ActivationDependencies> section to your feature.xml file. Here you can list the features your own feature is depending on.

According to the documentation on activation dependencies (http://msdn.microsoft.com/en-us/library/aa543162.aspx), the depending features get automatically activated if they are in the same scope: “If a Feature is dependent on another Feature at the same scope, and the second Feature is not activated when the first one is activated, Windows SharePoint Services activates the second Feature”

This is incorrect!

The second feature is activated automatically only if it is hidden!

I was recently contacted by one our customers with a request to change some permissions on some SharePoint sites. In normal cases this is something you can easily do through the user interface, only in this case they wanted to change the permissions on some 400 sites. And as you can probably imagine the permissions inheritance chain was broken or this would have been a trivial task. It is easy enough to programmatically loop through a bunch of SharePoint sites and set permissions but it felt overkill to fire up Visual Studio and create a throw-away console application that did this.

Read More

One of our SharePoint applications uses the property bag for storing information. During development and testing, we needed some easy way to set and change the information in the property bag. That is why this tool was created.

It is a simple console application that should be run on the SharePoint server as a user with adequate rights. It is invoked as follows:

PropertyBagAdmin <url> <property> <value>

Where <url> is the URL of the site, <property> is the name of the property in the property bag, <value> is the value to set the property to.

Note! If the property does not exist, it is created.

Use this tool at your own risk. Don’t use it if you are not sure what the property bag is or why you would like to set values in it. We have used it a lot ourselves, and have not run into problems with it. In short: don’t blame us if you break your SharePoint server using this tool.

Download PropertyBagAdmin.zip