Apr 25, 2009

Getting Started with SharePoint PowerWebPart 3.0

I’ve just released PowerWebPart 3.0 on my iLove SharePoint project at CodePlex. What can you do with PowerWebPart?

Write reusable SharePoint WebParts with PowerShell


  • Simple HTML Rendering
  • ASP.NET and SharePoint WebControls
  • Supports WebPart Connections (Row Provider/Consumer, Table Provider/Consumer)
  • AJAX enabled
  • jQuery enabled
  • Configurable parameters
  • SharePoint Object Model
  • NEW: PowerGUI Script Editor Integration
  • NEW: Script Signing
  • NEW: Custom Editor Parts written in PowerShell
  • NEW: Central Script Repository
  • NEW: Import and Export
  • NEW: Error Handling
  • NEW: Debugging
  • No compile, no packaging, no deploy, no iis reset deployment
  • Copy & Paste deployment
  • Anything PowerShell can do :-)

One of the major improvements is the automatically script signing. Only farm administrators are allowed to edit scripts in the UI. But what is when you export a web part, change the script and import it to a web part gallery again? The signature will be broken and the script will not run anymore. So exporting and importing is now secure. The script will automatically be signed when a farm administrator clicks on ‘Apply’ in the web part's editor panel. The signing key will generated randomly on installation, but can be changed anytime later. 

For installation and configuration see documentation.

Getting Started Screen Cast:

Soon I will post a PowerWebPart Tag Cloud example…

Apr 9, 2009

SharePoint Object Model - From SPFarm to SPListItem

In a layer model ASP.NET builds the UI Layer (and also the service facade), the SharePoint Object Model is the business layer and for sure there is also a data access layer. The data access layer is the dark side of SharePoint, because it’s mainly unmanaged. It’s a mixture of unmanaged code and T-SQL. Unfortunately the unmanaged part isn’t under the control of the developer and vulnerable for memory leaks. What you can do is query (only read!) the database with SQL directly, but isn’t that intuitive and not recommended. There are unverified stories that with SharePoint 14 there will be a one to one relation between SharePoint lists and database tables – we will see. To cut a long story short, the way of choice to interact with the SharePoint database is the object model.

The SharePoint object model is simply a beauty. I felt in love with it since I used it the first time about 6 years ago.

SharePoint Object Hierarchy Overview



Example – From Farm to List Item

Here is an example for beginners how to traverse from SPFarm to SPListItem. The objects used in this example can be found in two namespaces. From SPFarm to SPWebApplication in Microsoft.SharePoint.Administratation, from SPSite to SPListItem in Microsoft.SharePoint. The Namespaces resides both in the Microsoft.SharePoint.dll at “%commonprogramfiles%\Microsoft Shared\web server extensions\12\ISAPI”. Any clue where you will find it in SharePoint 14 ;-)

Always keep in mind that the object model is not remotable and have to run on the SharePoint server!

Console.ForegroundColor = ConsoleColor.Green;
Console.BufferHeight = 1000;

//Get local farm
SPFarm farm = SPFarm.Local;

//loop Services
foreach (SPService service in farm.Services)
//find WebService
if (service is SPWebService)
SPWebService webService = (SPWebService)service;

//Loop WebApps
foreach (SPWebApplication webApp in webService.WebApplications)

//Loop Site Collections
foreach (SPSite site in webApp.Sites)

//Loop Sites
foreach (SPWeb web in site.AllWebs)

//Loop Lists
foreach (SPList list in web.Lists)

//Loop Items
foreach (SPListItem item in list.Items)


If you will run it, it will run and run and run and look like this: image I call it the SharePoint Matrix ;-)