4 recommended tools for developing on SharePoint 2010 for newbies

I seem to have done a fair share of development work for SharePoint 2010. Prior to my current job, I had never used, touched or tried to understand the product. Then I moved onto my current job, a .Net engineering consultancy, which provides a number of services including “Business Collaboration software” (this is what SharePoint is designed to be). Pow! I was “thrown in the deep end”. I had to shift between producing awesome Silverlight 4 apps(all the rage at the time) to clicking on ribbons, creating lists, working with XML based definitions of various structures, all of which were linked & referenced using GUIDs. For any developer that has never worked with anything less awesome than proper code based frameworks (PHP developers exempt … my condolences), having to work with SharePoint for the first time can be likened to an experience comparable with cliff diving off Mt Everest on a scud missile, all on a cold, miserable, snowy day. Even though once you understand why, everything has its place in SharePoint but seriously, GUIDs! GUIDS! GUIDS!!
Some stuff that I have had to do with SharePoint includes:

• Creating custom site templates
• Creating custom connected SharePoint Webparts to serve context specific Silverlight content
• Creating custom content types, List definitions
• Synching issues from a SharePoint list to a TFS 2010 project
• Accessing site collections through the SP Client/Server Object model

As such, during my time working on SharePoint, I have come across a couple of tools which I though I may share with anyone out there in the same situation. I cannot honestly say I would have made much progress without them (note: click on the links to download the tool)

SharePoint CAML query Builder – U2U

CAML (Collaborative Application Markup Language) is SharePoint's custom query language used to allow interrogating lists through its API, specifying views, site building etc. Unfortunately, it is not as clean as something like LINQ or T-SQL. Its all specified in nested XML (surprise!).Thankfully, U2U’s CAML query builder tool saves me from insanity. The app allows users to specify & execute their CAML queries expressively, via a reasonably intuitive UI which can then be translated into CAML, run against a list on a SP farm etc. Simply outline what it is you want to search for and copy the generated mark-up. An absolute recommendation for any SharePoint developers arsenal.

         

SharePoint Manager

Available via Codeplex, this is a handy tool which acts as a SharePoint object model explorer. What this means is that it uses the SharePoint server object model (yes this means it has to be installed on the same machine hosting the SharePoint farm) allowing the user to interrogate all properties, view xml mark-up definitions, object hierarchy etc. of every server object including SPSites, SPWeb, SPList.While primarily aimed at helping SharePoint farm admins, its just works with any farm installed locally or on a dev server. Comes in real handy when having to create custom SharePoint content types and list definitions.

SharePoint ULS viewer

As with every web application, the SharePoint farm maintains a log for reporting errors etc. The logs themselves are quite verbose and navigating through them can be quite time consuming from a normal text editor, especially given the logs recycle at regular intervals. This tool constantly monitors those logs and allows users to view log entries in soft real time in a friendly interface that facilitates filtering, highlighting errors etc. There are a number of different versions of this tool available but I like this version the best. Useful to have in your corner during development.

SharePoint Designer

Published and maintained by Microsoft, SharePoint designer is aimed at allowing any user to connect with SharePoint and easily configure, design SharePoint components such as lists, custom content types, list views forms, workflows etc, all without having to physically browse the website. The list of things it is capable of are way too many to list on this blog, so feel free to hit the source link to find out more. One thing to remember, to allow SharePoint designer to install correctly, interact with any other office products, I recommend installing both products as either x86 or x64 bit.
So that completes my list of apps that make SharePoint development a little less painful. Hope this helps anybody out there starting out with SharePoint. May the Force be with you.

Using functions inside Powershell scripts

I had a task today that required mounting some content databases to my Sharepoint 2010 farm from an old WSS 3.0 environment that we are currently updating. Tasks like this often involve putting together a script file of some sort, a task that I quite frankly always find clunky and  boring to do and has always been performed on a need-to-do basis only in the past. However, I seem to have been bitten by the "what does this button do???" bug today and decided to investigate if I could make this whole experience a wee bit more exciting (and robust, god I do not want to mess up sharepoint content databases & have to roll back). Since I love working with a nix-style shell environment from my open-source days (hint hint: caffiene), I really love working with windows power shell. I feel it is MS's first real attempt at creating a decent shell scripting environment, and quite frankly PS cmdlet's are wicked.

Firstly, a bit of googling for some sort of IDE safe-heaven revealed the existence PowerGUI which can get for free (bit of $$ gets you a Pro version) and offer's a really wicked environment with PS specific intellisense & debugging enabled in a very Visual Studio'esque look & feel. Definitely a must have for nube's like myself.  The tool also offers VS2010 integration (see codeplex), which depends on the PowerGUI env being installed first but I was happy with the basic tool itself.

As for the scripting itself, my task required repeatedly calling the Sharepoint 2010 admin console cmdlet function "Mount-SPContentDatabase" which basically updates migrated content DB's from a WSS 3.0/2007 environment. What I wanted to achieve was basically execute the command for each content DB, if it is a success continue on, otherwise stop. So basically what I wanted to do was to write a function that I can call with my param's that will execute the call, and if unsuccessful exit the script. Oh and I also wanted to call this custom executable we made, called "MyLogTruncator.exe" to truncate sql log files on our db server that hosted the content databases prior to mounting them (otherwise you run the risk of running out of disk space if you dont have a lot to work with like me).

So basically I came up with this

function TruncateLog{param ($dbName, $LogFileName)

 .\MyLogTruncator.exe $dbName $LogFileName
 if(-not($?))
 {
  Write-Host 'Could not truncate log for ' $dbName $LogFileName
  Write-Host 'Exiting Script'
  exit
 }
}

function MountSPContentDB{param ($dbName) 

#this is the SP2010 cmdlet that will mount the content db's 

Mount-SPContentDatabase $dbName  -DatabaseServer 'MySharepointDBServer' -WebApplication 'http://MySPWebApplication'

 if(-not($?))
 {
  Write-Host 'Could not mount SP Content DB for ' $dbName
  Write-Host 'Exiting Script'
  exit
 }
}

#repeated calls to the functions 

TruncateLog WSS_DB1 WSS_DB1_log
MountSPContentDB 'WSS_DB1' 

TruncateLog WSS_DB2 WSS_DB2_log
MountSPContentDB 'WSS_DB2'

TruncateLog WSS_DB3 WSS_DB3_log
MountSPContentDB 'WSS_DB3' 

#other db's ......

As you can see, I have two functions specified with params to each function that I can call it with. The function body is enclosed with curly braces, followed by the first line outlining the list of params that the function can take. My TruncateLog function takes 2 parameters, the name of the db, denoted by the variable $dbName & the the name of the SQL log file to truncate, denoted by the variable $LogFileName. The function MountSPContentDB only needs to know the name of the content db to mount. Simply enough, once I have them declared I can continuously call them, passing in my parameters as shown.

Another tiny pearl I uncovered is catered towards adding a degree of robustness. If you could shift your attention to the PS if statement (which again is not very hard to write), you may notice a variable declared like so: $? . This is basically a boolean PS variable which stores the outcome of the previously executed statement, i.e if successful will store true otherwise false. I simply use this to make sure the previous command ran ok, if not I simply exit the script (call to "exit") and leave it to the user to work out what's gone wrong (the plethora of calls to Write-Host should outline where it failed hopefully). 

Well that was basically all I needed to do. Hope this helps. Happy shell'ing everybody.