Look alive. Here comes a buzzard.

I hate searching for this stuff every time I need it.  So here is a list of SharePoint site templates and their friendly names.

I recently did some load testing for a client and needed to populate our environment with sample data to simulate real-world usage.  This was my first occasion to use the tools released on Codeplex for this - WSSDW and MOSSDW.  As I was stumbling through the semi-documentation and samples that didn’t really work I started jotting down some notes.  This is a collection of these lessons learned - hopefully they’ll help someone else avoid some of the “WTF” moments I had
Download both WSSDW AND MOSSDW.
I ran into a ton of problems when I started because I only downloaded MOSSDW.  The samples don’t work without WSSDW - WSSDWLib.dll to be exact.  So download them both and install them in the same folder. 

You need to “Unblock” the help files (chm) before you can read them.
After downloading the help files, right-click, choose properties, then click Unblock.

Don’t bother trying to delete sample content. 
The tool just doesn’t work very well.  You’ll end up with an error and a bunch of left over content.  The best thing to do is just to create your sample site hierarchy under a single “Test” web and then just delete the Test web manually (or with stsadm) each time.  Note, you may have to use the Manage Site Content and Structure UI in MOSS so that you can delete webs with subwebs.

Creating a publishing page and publishing it is a two step operation.
This just seems weird so maybe I am missing something.  But if you want to create a publishing page, add content to that page, and publish it, you need two XML node actions.  The first node creates the page and adds content.  The second node publishes it.  For example:

<TestPage Name="Page1.aspx" PageLayout="ArticleLeft.aspx" openmode="modifyexisting">
  <TestHtmlFieldValue Name="Page Content" HtmlFile="MOSS_Intro.htm" openmode="modifyexisting"/>
</TestPage>
<TestPage Name="Page1.aspx" openmode="modifyexisting" Status="Published" />

You would assume you could just add the Status=”Published” bit to the first TestPage node.  But what happens is that the status gets set before the TestHtmlFieldValue node is parsed - so this action fails because the page isn’t checked out.  *rolls eyes*

Mixing and matching MOSS tags and WSS tags has some issues.
If you’re going to mix and match MOSS and WSS tags, be sure to use WSS tags to walk your web hierarchy.  The <TestArea> MOSS tag won’t provide context to children such as <Lists>.

Agile is THE ONLY way to build SharePoint applications.  Pure and simple.  If you think otherwise, sorry.  You are wrong.

Oh… you wanted an explanation?  Okay - here you go.

I could bore you with a bunch of background on Agile and what’s good about it, what the process is, what the core concepts are, etc.  But I won’t.  If I did that we would just go back and forth forever on the benefits/shortcomings of Agile development.  Instead I’ll get right to the point.

You do not know enough about SharePoint to fully spec a solution end-to-end.

Let me repeat that.  YOU (yes you), DO NOT know enough about SharePoint.  I know you think you do.  I know you think you know how everything works, how everything fits together, but you don’t.  And you know what?  Nobody does.

There you go.  Any application you want to build that has any level of complexity just cannot be fully designed up front.  There are too many unknowns at every level in the product.  Too many assumptions need to be made about what should work.  And we all know that there are dozens of unanticipated gotchas waiting around every turn.

SharePoint 2007 is a huge product.  It has a ton of little nooks and crannys each providing great functionality, but also hiding pure WTF, “why did they do it that way”, suprises.  SharePoint is just too big and too new for anybody to know it intimately enough to fully define a solution end-to-end without actually doing some trial and error implementation.  So if you’re doing trial and error implementation anyway, why not include the client and make them short iterations?

Okay - a few more quick benefits to this approach:

1. Don’t have to spend time documenting out of the box functionality that you don’t have control over anyway
2. Wireframes and UI designs are less critical because you can “design” on the fly using the out of the box UI - then identify the gaps where additional design elements or controls are needed
3. End up with less code/customization because once users see it out of the box, they quickly reach a “good enough” point.  You can focus your customizations where where adds real value.
4. The very nature of letting the user touch and feel the solution will change their requirements.  They will realize that certain things are less important than they thought while others are more important.  This is true with any application development but the fact that you can do so much out of the box in SharePoint means you can get to this point very very quickly.

So there you go.  Good luck.  We have a tough fight ahead of us convincing people that SharePoint is different enough to warrant throwing old waterfall methodologies away and trying something new.