Archive for June, 2010

The first Free SharePoint eMagazines released a couple of months ago and is still available at http://www.sdn.nl/IW/FreeMagazine/tabid/139/Default.aspx
Fantastic magazine with great content!

The second magazine can be downloaded at http://information-worker.org/freemagazine.aspx, keep up the great work!
Notice that Marianne and Mirjam and all the authors ofcourse are planning to publish the magazine on a regular basis: 3 to 4 times a year, awesome!

Looking forward to the next one!

In my previous post about the Developer Dashboard I showed you how to switch it on/off/on demand by PowerShell.
Ofcourse this can be done in Visual Studio as well:

SPWebService cs = SPWebService.ContentService;
cs.DeveloperDashboardSettings.DisplayLevel = (SPDeveloperDashboardLevel)selectedValue;
cs.DeveloperDashboardSettings.Update();

Make sure, if you make a webpart to set the developer dashboard level, you deploy this as a Farm Solution and deploy it to the Central Administration (Project Properties, set Site URL to your CA location).
The code will not work on another site, only at the CA, because the developer dashboard is a farm wide setting. If you do try to use the webpart in another site than CA, a security exception will be thrown:
System.Security.SecurityException: Access denied.

When you deploy the solution to the CA and try to use it on another site (or visa versa) you get the message:
A Web Part or Web Form Control on this Page cannot be displayed or imported. The type is not registered as safe.

After deploying a webpart to set the level of the Developer Dashboard, just go to the Central Administration e.g. to the Application Management page and edit the page. Two webpart zones will be visible and just add the webpart as you normally would.
An example:

A nice part of document libraries and lists is the version history. Nothing new, we had it in MOSS 2007, but I previously never dived really into the version history by code.
Recently I did and discovered something that might help you out some time. 

Let’s get the files of the Shared Documents folder and get all the versions by code:

SPDocumentLibrary sharedDocs = SPContext.Current.Web.Lists['Shared Documents'] as SPDocumentLibrary;
resultBox.Text = string.Empty;
foreach (SPListItem doc in sharedDocs.Items)
{
      SPFileVersionCollection coll = doc.File.Versions;
      if (coll.Count != 0)
     {
          resultBox.Text += 'Versions of ' + doc.File.Name + Environment.NewLine;
          foreach (SPFileVersion version in coll)
          {
                resultBox.Text += 'VersionLabel: ' + version.VersionLabel + ' IsCurrentVersion: ' + version.IsCurrentVersion + Environment.NewLine;
          }
     }
}

 Nothing quite impressive, I used the file version collection and asked some of the properties from the SPFileVersion. Here’s the result:

Notice that version 5.0 is the currently published version and a draft version 5.1 is available too.
Now let’s take a look at the version history of the file at the document library itself:

 

Hey, there is another version: 5.2! Why does this file not show up by code? 

There is another approach to get all the versions, let’s use the versions of the list items instead of the files: 

SPDocumentLibrary sharedDocs = SPContext.Current.Web.Lists['Shared Documents'] as SPDocumentLibrary;
resultBox.Text = string.Empty;
foreach (SPListItem doc in sharedDocs.Items)
{
     SPListItemVersionCollection coll = doc.Versions;
     resultBox.Text += 'Versions of  ' + doc.Name + Environment.NewLine;
     foreach (SPListItemVersion version in coll)
     {
          resultBox.Text += 'VersionLabel: ' + version.VersionLabel + ' IsCurrentVersion: ' + version.IsCurrentVersion + Environment.NewLine;
     }
}

And the result:
 

Notice that all the existing versions, including the current version, are displayed. Also the sorting is the other way around compared to the listing based on the file versions. 

The conclusion here is that the SPFileVersionCollection only shows the versions, without the current version and the SPListItemVersionCollection shows all the versions, including the current version. 

Suppose you want to delete or put all the previous versions of a file to the recycle bin, you can easily use the SPFileVersionCollection option demonstrated above. This way you don’t have to exclude the current version from your deleting code as you would with the SPListItemVersionCollection option. 

Here’s an example of this:

SPDocumentLibrary sharedDocs = SPContext.Current.Web.Lists['Shared Documents'] as SPDocumentLibrary;
resultBox.Text = 'To recycle bin: ' + Environment.NewLine;
foreach (SPListItem doc in sharedDocs.Items)
{
     SPFileVersionCollection coll = doc.File.Versions;
     if (coll.Count != 0)
     {
          resultBox.Text += doc.Name + Environment.NewLine;
          doc.File.Versions.RecycleAll();
     }
}

The result of questioning the SPFileVersionCollection after this action:

The result of questioning the SPListItemVersionCollection after this action:

Notice that the current version of the file still exists after the recycle action. With the SPFileVersionCollection there is one version besides the actual current version, which is not listed here. This is because the actual current version is still a draft version.
With the SPListItemVersionCollection both versions are listed, the top one is the draft, the second the published version.