SharePoint has a great API for most things, but some of things seem a bit lacking.

I recently had a need to auto-create folders inside a document library. Basically, like mkdir with command extensions does on the command line. If directory x exists, but x\y doesn't, mkdir x\y\z will mkdir x\y and mkdir x\y\z.

After some struggling, here's what I ended up with:

    Public Shared Sub CreateDocLibFolders(ByVal url As String)
        Using site As New SPSite(url)
            Using web As SPWeb = site.OpenWeb()
                If url.StartsWith(web.Url) Then
                    Dim folder As SPFolder = web.RootFolder
                    For Each segment As String In url.Substring(web.Url.Length + 1).Split("/")
                        Dim nextfolder As SPFolder = web.GetFolder(folder.Url & IIf(folder.Url.Length > 0, "/", "") & segment)
                        If Not nextfolder.Exists Then
                            folder = folder.SubFolders.Add(nextfolder.Name)
                        Else
                            folder = nextfolder
                        End If
                    Next
                End If
            End Using
        End Using
    End Sub

Okay, I know it doesn't look like much, but that code represents some hard won knowledge. The main thing was dealing with folders that had spaces in them. Before, I was System.Web.HttpUtility.UrlDecode()ing them, but my use of .Name on a .Exists=false proved to be much more elegant. Even though I'm doing a GetFolder on a escaped url, the .Name property returns a nice, suitable for passing into SubFolders.Add(), de%20ed name. But why use this ugly indirect path string building technique? Well, I could not find an exception-free way of doing existence testing of a folder other than web.GetFolder() which, of course, needs a web relative url -- this lead to the more clunky looking GetFolder expression.

RaiseEvent OnReligiousArgument

For the two people that read this blog (me and uh, that might be an exagerated figure) the reason my snippets have been in VB.NET lately is because I think VB.NET is underloved in the SharePoint community. VSEWSS, for example, is a C# only club. Heck with that. It doesn't provide enough juice to justify the opaqueness of its wsp builder. VB.NET has some nice features and I like taking advantage of them -- I know both cold and I make no apologies for choosing VB.NET. If you are one of those C# 1337ists... run the benchmarks and tell me its so much better. Tell me what it does so much better that it makes up for the utter lack of exception filters, XML literals (VB9), pleasant event raising, beyond 1980s-era switch/select case, optional parameters, automatic by-reference parameters for callers, array resizing, and procedure scoped static vars. I'm not saying C# is worse -- it's like the difference between ibuprofen and acetaminophen. Minor advantages in some edge cases both ways but they all fix most headaches.

I've seen some comparisons between the two languages before on the net, but none seemed entirely complete. If I ever am put in jail with nothing but a toilet and a laptop for a few years, perhaps I'd blog /the/ definitive list.

For those of you thinking of writing in your reasons why C# is soooo superior to VB.NET, please refer to the Logical Fallacy article on Wikipedia before embarrassing yourself. Reasons like "real programmers use semicolons" or "only a moron would use a language with the word 'basic' in the name" will be ridiculed mercilessly. There are some valid arguments for C# and one could make an equally compelling valid case for it over VB.NET.