What Are The Biggest SharePoint API Mistakes?

The most prevalent SharePoint API mistake that I see is the lack of freaking Exist properties on proxy objects.

What do I mean?

One can’t do this in order to test, for example, whether a SPList object exists:

public static void DoesMyListExistIDunno()
SPWeb web = SPContext.Current.Web;
SPList list = web.Lists[“Heres My List”];

bool areYouThere = list.{An Exists Property Would Be Sweet Wouldn’t It?};

As opposed to this, a developer is forced to do this (or a mild variation of this, I am just using the LINQ because it looks fancy) which is lame:

public static bool InspectForList(string listName)
var results = SPContext.Current.Web.Lists.Cast().Where(item => Equals(string.Compare(item.Title, listName, true), 0));
return results.Count()> 0;

What do you think is the most rampant and cumbersome? I am interested in what other people see as being a pain in the butt.


11 thoughts on “What Are The Biggest SharePoint API Mistakes?”

  1. I think they should have provided 100% “dispose every time” SPWeb, SPSite, etc. objects. The SharePoint internals would work out whether the disposal method does anything (!!!), leaving we the API consumers, to dispose every time.

    Much simpler rule to follow.

    Also, I want them to change all the getters and indexers to methods, because it seems like everyone in the world assumes that getters and indexers return the same object every time. Example:

    $web.Lists[“Announcements”].Visible = $false

    Third, I’m not a fan of the way SPSite/SPWeb/SPList/SPListItem/etc are proxies to the real objects, i.e. that some of their data is stale, but other data is refreshed every time you ask for it. Good recent example, I had a bug where I a) ran $spListItem.File.MoveFile(“tosomewhereelse”), b) couldn’t use $spListItem anymore, because all methods returned errors, because the file it internally points to moved. So I had to manually get the item again. …This behavior is okay, if it’s consistent between methods; either consistently stale, or consistently fresh.

    Fourth, I wish the Feature/Solution framework included a way to separately deploy configuration. This isn’t so much a mistake as a feature request, but everyone needs it, and maybe they should have picked this up pre-RTM.

  2. Peter:

    Your first one I TOTALLY agree on. The requirement for manual disposal is pretty ridiculous, but I think it’s more the poor implementation of IDisposal then anything. The solution of “more tooling” to ensure the disposal is pretty weak.

    Second point, totally. I have run into that a TON.

    Third point, haven’t run into it, but I see the point. I do understand it based on your example though, and the consistency would be a nice attribute!

    Fourth point, I agree that this is a huge pain! I hope in the next revision this is taken care of.

  3. Fifth, I wish CAML (query language) disappeared and was replaced with LINQ to CAML.

    I wish the other CAML (every bit of XML everywhere) was replaced with code. We’re not getting any of the benefits of XML anyway, so why not instead of building a ListDefinition in XML, declare a ListDefinition class with a bunch of required getter properties? What’s the difference? What’s the disadvantage of code over XML?

    Instead of declaring a Feature manifest in XML, why not move the data to the Feature Receiver class in a bunch of public read-only properties?

    And I shouldn’t say that XML is the problem, or that you can’t generate the XML for SharePoint to use, like it always has–the problem is that I can see and am editing the XML manually, by hand.

  4. Peter: Continually recompiling assemblies to update or modify a list definition is a hassle. I much prefer CAML, or at least an XML-based language for this. Luckily WSS4 will, most likely, replace CAML View schema with XSLT.

    Also, I don’t see the big issue with writing the XML by hand. How would this change if you had to write the .NET code by hand? With John Holliday’s CAML.Intellisense you’ll get really good intellisense as well.

    For a lot of CAML tasks you can also build the object in the Web UI and then extract the CAML required to put this in a feature.


  5. I would reply in full, because there’s a lot to say about SharePoint development, but quickly: JavaScript-in-HTML-in-XSLT-inside-HTML gives me seizures.

  6. Rather than Where/Count, just use Any:
    public static bool ListExist(SPWeb web, string listName)
    return web.Lists.Cast().Any(list => string.Equals(list.Title, listName));

  7. Oskar,

    A bit late on your response but, while the methods you describe do a query of all list items, there is a better way to count the items in a SPList, try using myList.ItemCount, wich won’t have to query all the contents, there’s a way for adding an item without having the same effect but the workaround you have to make is so big, it’s not worth it most of the time (google ProcessBatchData).

Leave a Reply

Your email address will not be published. Required fields are marked *