Geeks With Blogs
David Jacobus SharePoint Consultant
For the last 1 1/2 years I have browsed and used content from hundreds of blogs that I have researched in the performance of my position as a SharePoint developer. I have needed to do this as SharePoint 2007 has many books which have shallow dives into the API only a few offer insights into “Best Practices” and the best way to accomplish SharePoint customizations. This blog entry is some pay back for all those bloggers whom I have used to ensure successful engagements.
In the last 16 months I have had 4 major clients and a few smaller ones and for a few of the engagements I have found the need to provide the client with a site definition for a common division/department site. In the beginning I used a couple of books which provided basic instructions on how to copy the SharePoint team site and configure it to meet specification. I was able to make it work but I knew that I had to spend too much time with the modifications to list definitions, and that humongous onet.xml file! 
When I first entered the SharePoint arena I did most all customizations through XML files: Content Types, etc. After my 2nd client I realized that although XML can get the job done it is ugly and exacting! Case sensitivity and a misspelled word could bring down a SharePoint installation especially when dealing with content types. Although XML is still a requirement much of the hassle can be alleviated with a combination of XML and code (C#). Therefore, this post is my take on best practices for Site Definitions as a combination of XML and code (C#) and a methodology to use in the development of site definitions.
Consultants/Developers need to have a common delivery mechanism of SharePoint Artifacts to the client. Two CodePlex tools are the mainstream tools used in the industry: STSDev and WSPBuilder. I have used both and they are time saving and first class tools for SharePoint solution files. I am a firm believer that as a developer we only deliver solutions to the client that can be installed onto client servers either directly onto the production server(s) or through the development, test, and production sequence. I have worked with some who will deliver direct SharePoint Designer solutions (me in the beginning) that are not repeatable installations but repeatable configuration solutions, they are fraught with errors!
For this blog entry I will focus on a solution built with WSPBuilder but I use STSdev in much of my work! Okay, let’s get one false impression that is out on the web thrown out! Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2 is not a POS especially the SharePoint Solution Generator. In the 2005 version I wouldn’t use it because of all the GUID attachments to list names, etc which made the solution ugly and incomprehensible to the end user. But in VS 2008 the Solution Generator is a first class tool! I tested it on a custom teams site with 11 custom lists, custom list views and with custom dispform’s. The solution replicated a STP with full fidelity!   However, Microsoft put much of the under pinning’s in hidden features and custom build processes! So if you are going to use it for site definitions other than a custom team site then a reproducible solution is needed and thus the purpose of this blog entry!
Posted on Monday, October 27, 2008 11:36 AM | Back to top


Comments on this post: SharePoint 2007 Site Definitions Part 1 (Basics)

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © David Jacobus | Powered by: GeeksWithBlogs.net