Something that I have to do time and again is get some element of SharePoint’s heirarchy, such as a site collection, site, list or item. This is pretty typical – that’s why we all use
USING to ensure proper disposal of SPSites and SPWebs, right? But what happens if the thing you’re after isn’t there? What exception get’s thrown? Well, this should be pretty clear:
//FileNotFoundException if doesn't exist
using (SPSite site = new SPSite(siteGuid))
//FileNotFoundException if doesn't exist
using (SPWeb web = site.OpenWeb(webGuid))
//SPException if doesn't exist
SPList list = web.Lists[listGuid];
//ArgumentException if doesn't exist
SPListItem item = list.GetItemByUniqueId(itemGuid);
catch (System.IO.FileNotFoundException fileEx2)
// Site or Site Collection Not Found
catch (SPException spEx2)
// List not found
catch (ArgumentException argEx2)
// Item not found
Hopefully that might prove useful to someone – and a good reminder for me.
This is a seemingly simple task – given a List or Library in SharePoint, how do I get it’s URL? The difficulty here is that a List has multiple URLs – one for each View on the list. We can get those URLs, but sometimes you really just want the URL to the list, without the /forms/something.aspx bit too.
For example, you might want http://server/siteCollection/site/lists/somelist . If you entered this URL, you’d be taken to the default View for the list, so you don’t really need the extra /forms/… bit to identify the list – that’s all about identifying the view.
Sadly, though, there is no SPList.Url property or equivalent on the SPList object. So, how can I get a list’s URL? Continue reading “Get the URL of a list”
This is an example of programmatically creating a content type (based on the Document content type) and adding it to a list. I’ve not added any extra columns or anything – but we could have.
string name = ...
SPList list = ...
SPContentType baseContentType = web.ContentTypes[SPBuiltInContentTypeId.Document];
SPContentType type = new SPContentType(baseContentType,web.ContentTypes,name);
I like mail enabled lists – they’re not perfect, but they are nice, and most folks can handle working email.
Sometimes, though, you want to programmatically create and enable these lists. That’s cool – but how do you figure out the email address of the list afterward?
You can get the first part of the address from the SPList object’s EmailAlias property. But that’s only the bit before the ‘@’ sign – what about the end of the address? Well, you get that from the farm:
emailAlias = list.EmailAlias + "@" + SPFarm.Local.Services.GetValue<SPIncomingEmailService>("").ServerDisplayAddress;
This gets the rest of the address (in my case ‘sharepoint.virtual.local’). Job done.
Tobias Zimmergren tweeted today asking
Anyone got recommendations to how you modify RSS-Settings for an SPList object using the API?
Good question. The SPList object does have a property EnableSyndication that gets or sets whether an RSS feed is available. There is also an property ‘AllowRssFeeds’, but it is, apparently, read only.
So, you can set whether one is allowed or not – but there are a lot more settings. What about controlling them programmatically? Continue reading “Control the RSS Feed Settings on an SPList via the API”
Being able to mail enable a sharepoint list is pretty cool; once enabled an email can receive email, save attachments, etc.. But what’s the address of the lists? How do you enable it? How are attachments stored, and how do we decide who to let email it?
Well, for a customer we wanted to email enable a list with an address based on the site’s title. This meant that the site would have to be created before we could enable the list. So, I stapled a feature to the site’s definition, and used a feature receiver to run my code. Continue reading “Programmatically create and configure Mail Enabled lists”
An interesting post by Rob Garrett about avoiding using SPList.Items.Add() – as referencing SPList.Items causes you to get all items in a list, and that can be pretty slow. He does suggest a solution.
I must confess, I’m surprised. I mean, what he describes makes sense – and also explains why have both SPList.ItemCount and SPList.Items.Count (same problem – and the former should be faster) – but surely there is some equivalent already build, some SPList.AddItem() to do it for you? Guess not.
Might be a small optimisation, but it starts to become clearer why the 2000 item recommendation…
At some point, I’ll try and generate some metrics, and then we’ll see when it becomes more efficient and how much so.