Verifying all the parts of a Sharepoint application

Trying to build a 5,000 piece Lego Death Star while simultaneously balancing on a highwire would not be the easiest act to perform nor probably the smartest. However I am doing just that as I am currently working on a SP 2007 application consisting of over 30 development projects, and at the same time trying to migrate the project from TFS 2008 to 2010, perform the first Sprint of a newly conceived Agile development process, and deploy the new sprint to a test environment with no standard deployment policies in place. Although it wouldn’t be smart or easy to build the Lego Death Star on a highwire, small private companies like mine do what they need to do and nimbly turn on a dime for the customer so this SP project is being done regardless of difficulty.

When I came on to this project, we began to move the single Visual Studio solution containing +30 projects to 7 solutions each containing a handful of projects. At the same time, we worked to migrate from TFS 2008 to TFS 2010. After spending long hours of daylight and evening time with the lead developer, working thorough all of these issues and becoming more knowledgable about the system, I became the lead on one of the major SP sites named YMWCB (actual name withheld to protect the guilty.) YMWCB is that 5,000 piece Lego Death Star.

We work in a standard virtualized SP development environment where each person has their own virtual machine complete with SP, SQL Server, and Visual Studio. So after the migration of the codebase, seperating the 32 project solution into smaller solutions, and after working out all the kinks, I was tasked with setting up a few VMs each containing an installation of YMWCB  for the testers and a developer.   Installing YMWCB requires running some Powershell scripts, batch files, a command line executable, and performing some manual steps in SP. After doing all of that, the site will usually still blow up at which time Visual Studio is used to attach its debugger to the W3WP process to figure out what’s going on. After this debugging, another round of scripts is ran and more manual SP steps are performed. This process of site explosions, debugger, and scripts goes on until finally everything is in place and YMWCB runs without trouble.

I’ve been through this process so many times, that I’ve come up with an acronym for it- EXDES (EXplosion, DEbugger, Script). This acronym is said with the same pronunciation a deep southern Baptist would use to pronounce the word EXODUS. And BTW I have a license to talk about southerners as I spent 15 years in Arkansas.

So, back to my story of putting together my Lego Death Star while trying not to fall to my death: After experiencing the 3rd EXDES process, it dawned on me that I should write a utility which validates the YMWCB installation and report which pieces were missing or mis-configured. I wrote the utility as a C# command line application with a base class named BaseVerificationModule and multiple child verification module classes which would each verify some portion of the YMWCB installation.

I wrote a verification module class for each of these:

1. Verify each subsite of the YMWCB site has the proper groups.
2. Verify each of the above groups are given the proper permissions.
3. Verify each YMWCB subsite’s document libraries have the appropriate event handler registered for the Added, Updated, and CheckedIn actions.
4. Ensure the event handler registered above is the current version available in the GAC.
5. Verify the YMWCB top level site contains the proper custom permissions and that these custom permissons have the correct attributes (e.g. OpenItems, CreateAlerts, ViewPages, etc.)
6. Verify the top level YMWCB site contains the SP lists used to hold lookup information (such as region or area) used by the main application/web parts and ensure these lists contain the proper data.
7. Verify each YMWCB subsite has 2 lists named ‘Draft Work’ and ‘Archived Work’ (names changed, again to protect the guilty.)
8. Verify the YMWCB top level site has the correct lists in it as well.
9. Perform a GAC verification on each of the 18 application assemblies. This includes:
   1. The assembly is in the GAC.
   2. There is only one version in the GAC.
   3. The assembly can be loaded from the GAC.
10. Verifies certain lists contain certain custom added columns.
11. Verify the web.config in the SP virtual directory. This includes:
    1. Ensure the AjaxToolkit is set to 1.0 in the <assemblies> section.
    2. Ensure the necessary custom web parts are configured int he <SafeControls> section.
    3. Verify the database connection string in the <connectionStrings> section can be used to open a connection to the database.