Version Trimming

SharePoint’s ability to keep multiple versions of a document is a great benefit — but it can also gobble up space like Cookie Monster can eat cookies.  Several clients have had issues, particularly when trying to get a migration right, where there are too many versions of a document in their database chewing up space.

Other SharePoint users face the long term maintenance nightmare of trying to control the maximum number of versions of a document when they no longer have control of their users.

Because of this, I’ve developed a command line tool (which can be easily scheduled) which will go in and “version trim” a document library. You tell it the maximum number of versions that you want to allow for a document in a SharePoint site and it will go delete all of the versions in excess of the number you specify.

The tool is web service based which means it can be run from any machine — it doesn’t have to be run from the server.

I’m finishing up some Alpha level testing this week but will be looking for beta testers early next week.  Anyone interested?


Link: SharePoint as a time tracking tool.

If you read this blog at all you know that I rarely link to other content directly, however, I thought this was an interesting idea…

Easy Time & Billing with SharePoint, Outlook, & Excel (and VSTO too!)
These popular office system applications reduce the pain of recording and reporting your time, with very little code required.

by Ty Anderson


Is Everything in SharePoint a CAB file?

I’ve known for quite a while that SMIGRATE backups (FPB)s were simply renamed CAB files.  Today I had a collegue show me that STP files are just renamed cab files too.  When you create a template — either for a list or a site the resulting STP file is just a renamed cab file with a manifest.xml file.  I’m not sure what I’m going to do with this new found knowlege but it is definitely cool.  (It might make it possible to apply a template to a different site definition for instance.)


SharePoint and XPath

I blogged earlier about using the XmlNamespaceManager to get back nodes from SharePoint XML fragments.  I found a better way (with the help of some BizTalk MVPs that I got to hang out with recently).  Instead of doing /wp:Fields/wp:Field or whatever nonsense that you need to do to get the XmlNamespaceManager to work use the local-name() function so … /*[local-name() = ‘Fields’]/*[local-name()=’Field’]

I’m sure someone will tell me why that isn’t very performant … but I don’t care it works, it’s clear to read, and I don’t have to go through hoops to get the XmlNamespaceManager hooked up.


Doing the impossible: Maurice Prather clarifies AppDomain Usage

Maurice Prather’s original post on AppDomains to get around some issues with impersonation and the object model was great.  It was an approach that works to allow most applications to do what they need within the SharePoint world — even if SharePoint doesn’t allow the user to directly perform the action.  His update fills in some small holes in the original article — including one or two that I must admit I fell into. Maurice was kind enough to help track down the issue (the second call to impersonate that I wasn’t doing but he was)  and get things straightened out.  My problem was the one exposed by Mike Donovan on IRuntimefilter getting roles for a user.He worked around it with a web service call, but that’s not an option in my environment since performance will definitely be an issue.

I can also say that a SharePoint architect that I placed with another client has used the AppDomain technique to get by a wide variety of issues.  So in short, if you need to do impersonation, this is the way to do it…



Useless SharePoint Error Messages

I have been promising for a while to get some of my favorite error messages up … here are a few.  I couldn’t find my all time favorite — Catastrophic error.


Preventing users from using the UI to manage web parts

There has been a fair amount of talk lately about how any web part page in SharePoint — including many pages like list pages that people don’t think are web part pages — can have the web parts manipulated by simply adding parameters to the query string.  Those parameters cause the ToolPartPane to appear even if there was no administrative control on the page to cause it to appear.

This is true of the existing pages, but you can create your own site definition that doesn’t allow users to use the user interface to modify the web part placement or even add new items to the web part zone.  The WebPartZone class (and consequently the WebPartZone tag) support three interesting attributes/properties…

  • AllowCustomization – Indicates whether customization is allowed or not.
  • AllowPersonalization – Indicates whether personalization is allowed or not
  • LockLayout – Indicates whether the layout of the zone is fixed — and can not be edited.

Quick testing shows that AllowCustomization must be set to true and LockLayout must be set to false for SharePoint to even show the web part zone in design mode.  Further investigation has shown that using the web services calls to modify web parts in the web part zone still seems to work — and editing the page in front page including web part placement still seems to work as well.  In other words, it’s possible to prevent users from modifying web parts in special zones, like navigation, while retaining the ability to control web parts in these special zones via code.


Folder Taxonomy, Path Limitations, and Meta Data

I was searching out some things and ran across an old blog entry from Bil Simser talking about the limitations of using folders because of path length limitations.  Here are a few observations from a recent client experience.

1) The path limitation is indeed 255 (or 256 characters).  It’s documented in some of the planning documents (and in a KB article as well if memory serves.)

2) The idea of using meta data to categorize information instead of folders has at least two limitations …

a) WebDAV doesn’t natively support the assignment of meta-data during a save operation.  Therefore saving with applications which are not fully SharePoint aware is a bad experience.  The documents end up in the “root” of the view since they have no data to categorize them.

b) Retreiving files without context from a SharePoint document library can be very difficult without the property information.  Since the WebDAV File-Open dialog doesn’t understand the meta data it can be frustrating to find the right document to email to someone when the file name doesn’t contain all of the useful information.  One solution around this particular problem is to use the free Outlook Power Tool for SharePoint from Winapp Technology.  Of course, that doesn’t solve the problem when you’re trying to use a file from another application.

In general… Use meta data if you need the ability to reorganize the data in multiple hierarchies.  Use folders to make it easy to use within non-SharePoint enabled applications.

As a sidebar, the experience on SharePoint with WebDAV is much better in Windows XP vs. Windows 2000.  Every application I’ve tested has been able to save to SharePoint via WebDAV in Windows XP.  The same applications have trouble with Windows 2000’s support for WebDAV.  XP also allows files to be dragged from one WebDAV folder to another where Windows 2000 does not.


XML Namespaces and Bad Exception Propigation

Two quick things …

1) If you’re trying to use XPath on XML you get back from SharePoint… don’t forget you’re going to need the XmlNamespaceManager object to use with SelectSingleNode or SelectNodes to get back what you’re looking for.  I repeatedly forget that SharePoint uses XML Namespaces extensively… and that using SelectSingleNode and SelectNodes does require namespaces in the XPath.  (Today was lesson #3.)

2) Bad error handling.  You may find it interesting to note that the WebPartPages web services’ GetWebPartProperties method doesn’t seem to throw soap exceptions.  I ran into my favorite “Cannot complete…” error again.  However, it didn’t show up immediately because rather than throwing a soap exception this particular method returns the error as a comment node — rather than throwing an error.  So you’ll have to look for comments one level down from the root.  (Sidebar: It doesn’t look like this web service even works against SharePoint Portal Server areas.  At least – I keep getting an error about XML namespaces — back as a comment.)


SharePoint: An update on IRuntimeFilter

A few weeks ago I posted on the IRuntimeFilter interface in SharePoint. Here are a few updates…

1) I’ve validated that IRuntimeFilter’s CheckRuntimeRender() method is only called when the IsIncludedFilter property of a web part is non-null.

2) By default, Windows SharePoint Services will put administrators and web designers into a shared page view rather than in a my page view.  The net effect is that the shared page isn’t a personalized view and therefore IRuntimeFilter’s CheckRuntimeRender() method isn’t called.  To fix this create a new site definition and add the following tag into the <HEAD> tag.  <META name=”WebPartPageDefaultViewPersonal”>  Then make sure you do an IISReset so it can take effect.  (You’ll have to create a new site to see this.)

3) ValidateRuntimeFilter() is called everytime the web part is serialized — which is often.  So keep the code that you write in this method very simple.

4) If you decide to do post backs in the chooser form that you create, you’ll need to add a tag to the <HEAD> tag.  That tag is <base target=”_self”>  If you don’t do this then the form will cause a new window to open.

My next step is to fix some impersonation issues with roles (the ones that Michael Donovan mentioned to in his post.  From there, I’ll be writing a IRuntimeFilter chain to allow the Portal audiences IRuntimeFilter to run side-by-site with our own IRuntimeFilter.