Ad-hoc contributions

Jun 4, 2009 at 4:13 PM

I may be interested in actually joining this project as a contributor, but in the meantime, let me offer some ad-hoc contributions.  I'll start with SPList.AddItemOptimized() since I didn't see that already included, I'll review my personal library and add as I see methods missing from SPexLib:

public static SPListItem AddItemOptimized(this SPList list)
  const string EmptyQuery = "0";
  SPQuery q = new SPQuery {Query = EmptyQuery};
  return list.GetItems(q).Add();

(Could be done all in one line, of course.)

Background info here:


Jun 4, 2009 at 4:50 PM

Added as SPList.AddItem with a link to your post. I would hope any method we include will be optimized. ;)

Great suggestion!

Jun 4, 2009 at 4:53 PM

I quickly went through the methods that are there so far in SPExLib, and culled from my own library those that overlapped.  I posted the filtered result to my blog: these are extension methods not currently in the SPExlib project (as of June 04 2009).

See for the complete code.

Jun 4, 2009 at 7:28 PM

Awesome, there are some really nice nuggets in there. I'll include them and try to finalize a new minor release as soon as possible.


Jun 4, 2009 at 8:39 PM
Note the simplification of the SPContentTypeCollection Contains method - using lamdas is neat and all, but not necessary - just check for the indexer to return a null value.  Both the SPContentTypeId and string based indexers are based on hashtables that will just return null if the key is not found.  From Reflector:

public SPContentType this[string name]
        return (this.m_htName[name] as SPContentType);
public SPContentType this[SPContentTypeId id]
        return (this.m_dictId[id] as SPContentType);
(On the other hand, the int-based indexer WILL throw an exception if the index exceeds the stored number of values, but then it is not particularly useful in most cases.)

Oskar Austegard |

On Thu, Jun 4, 2009 at 2:28 PM, wictor <> wrote:

From: wictor

Awesome, there are some really nice nuggets in there. I'll include them and try to finalize a new minor release as soon as possible.


Read the full discussion online.

To add a post to this discussion, reply to this email (

To start a new discussion for this project, email

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at

Jun 5, 2009 at 1:55 AM

Since the SPExLib is not restricting itself to pure SharePoint API extensions, how about adding some form of extended object string format method?  I created a very crude one at, brains much larger than mine did similar things, summed up by Phil Haack (here and here) and Peli ran them all through Pex (here).

I had also intended to extend this to allow easy formatting of an SPListItem:  E.g. if you have an item with Title = "My Item" and SomeField = "Some Value" and OtherField = "42", it would be nice if you could output the item as a formatted string like this:  item.FormatAs("{Title} has {SomeField} - it is {OtherValue}") to render "My Item has Some Value - it is 42".


Jun 5, 2009 at 2:19 PM

Looks like a good addition as well. And yes we are not restricted to extending the SP API only, but the extensions should be of great usage when developing for SharePoint.

Jun 5, 2009 at 2:28 PM

Hi Wictor,

I have over 15 classes of extension methods (don't get too excited as a lot of them only have 1 or 2 methods). Almost all of these are SharePoint-related. They consist of several TryGet style methods to avoid SPException, uses of LINQ to query the XML of a collection rather than looping through it (may give performance improvements but not tested), and other bits and pieces of missing functionality.

What should I do with these? Test more throughly and publish them to my blog like austegard for inclusion?

Thanks, Alex.

Jun 7, 2009 at 6:53 AM


it would be nice to see a summary of your extensions, post them somewhere or send them to me.

About the try/catch vs Linq style: I did some testings on this sometime ago and it's hard to decide which one outperforms the other:

  • try/catch is faster when you are more likely to find something
  • Linq is faster when you don't find the item
  • Linq is faster on many iterations (mixed hits or no hits)
  • Linq is slower on the first hits (cold-start requires the Linq assemblies to start up)

I have a few goals for SPExLib

  • Fix the missing/broken API's in SharePoint
  • Make it easier to code (but not making every two-line command into one-liners)
  • Help developers to make dispose-safe code
  • Make your code perform better

If you think that your extensions fit here, then I'm happy to include them


Jun 9, 2009 at 1:32 AM

A couple more:

/// <summary>Converts the date time for use in SP queries.</summary>

/// <param name="dateTime">The date time.</param>

/// <returns>The ISO8601 format of the datetime</returns>

public static string ConvertForSPQuery(this DateTime dateTime)


return SPUtility.CreateISO8601DateTimeFromSystemDateTime(dateTime);



/// <summary>

/// Returns the list with the specified <b>web</b>-relative URL, or null if not found.

/// <example>

/// <para>If the Web URL is http://foo/bar/ and the List URL is http://foo/bar/Lists/blah, 

/// then <c>myWeb.GetListOrNull("Lists/blah")</c> will retrieve the list.</para>

/// <para>This contrasts with <see cref="SPWeb.GetList()"/> which requires the <b>site</b>

/// relative URL, e.g. <c>myWeb.GetList("/bar/Lists/blah")</c>.

/// </example>

/// </summary>

/// <param name="web">The <see cref="SPWeb"/>.</param>

/// <param name="listRelativeUrl">The list URL relative to the <see cref="SPWeb"/>.</param>

/// <returns>

/// The <see cref="SPList"/> instance, or <c>null</c> if not found.

/// </returns>

public static SPList GetListOrNull(this SPWeb web, string webRelativeListUrl)




string siteRelativeListUrl = (web.ServerRelativeUrl + "/" + webRelativeListUrl).Replace("//", "/");

return web.GetList(siteRelativeListUrl);


catch (Exception) { return null; }


Jun 9, 2009 at 9:36 PM

Sweet. I'll look into them as soon as possible. Have to finish up some "real" work at the office before deadlines...


Jun 23, 2009 at 12:16 AM


I've started to add some of the contributions in this thread (some of them are renamed to match the rest of the SPExLib APIs). I've not added complex extension methods, but instead focues on those extension methods that either

a) simplifies the development
b) fits in to the current set of extensions
c) makes your code more readable
d) makes your code perform better
e) makes you code more safe

I'm sure that you would like to see all kind of extensions here, but to make SPExLib useful I try to focus on the above points


Jun 23, 2009 at 9:16 AM

I agree with your thoughts on this. It's a good idea to have a neat, focussed framework. I'm also glad I don't have to decide what goes in! :-)

Jun 23, 2009 at 3:09 PM

FWIW, I agree too.  Similarly to jQuery this needs to be a core framework, each developer can always have their own set of extension methods.

It may be good to continue with ad-hoc contributions on these boards though, even if the methods don't make their way into the core release, other developers can surely benefit.

Jun 23, 2009 at 3:29 PM

Agreed - keep em coming...