BinaryJam

Is it me ?  Have I missed something ? Are STP’s the best thing on the planet for quickly creating SharePoint sites ?

Or is it as I believe the biggest pain in the backside for SharePoint developers to pick up someone else’s SharePoint project to make changes to the site definition pages only to discover they were hacked together in the interface saved as an STP and included in your project.

This is now the case for me on two of my inherited projects, I hate them.  Now I know that if you create standard site templates with an onet etc, once created, there are elements of the definition that are now content and would have be be manipulated via the API to change them (or interface). But consider if you have a problem and are searching in a HUGE project for where your specific list might be or other such content, can you find in in Studio by searching ? No you can’t cos it’s all cabbed up in a file.

So my advice to anyone even considering using STP’s, think again are you doing it cos it’s quick and your a contractor soon to leave the company anyway so what the hell, or are you a developer who might have to make changes and maintain your project.  Seriously think twice, is this the best way to develop this solution, is there some advantage to an STP over a site def ? think before you start hacking away.

I’ve had a right game with this Sharepoint Versioning problem.

Now those of you used to writing .NET but maybe not SharePoint will be used to having AssemblyVersion attributes set in the AssemblyInfo.cs files.

This is something I took into my last SharePoint application for wss3.  Now in SharePoint 2003 I got used to not setting the version number but it slipped my mind for WSS 3.0.

My particular problem was I had some ItemAdding/Updating List events.  These were configured to fire in one of my Assemblies. My build server would automatically increment version numbers in AssemblyInfo.cs and in all associated .xml files in the features, very clever I thought at the time.  Now I needed to update this assembly and modify some code in these events.

I made those changes and installed it and all of a sudden none of the events were firing at all.

This is because when a list is created the EventReceiver details of the feature are not read from the XML file but are stored against the List in the content database.  This makes some sense as if you update the list template then you can update the EventReceivers as well and have different versions of a list definition with different handlers.

In my experience it’s more likely that you will want to modify all the existing lists and template as your probably implementing a fix, especially if using SharePoint as an app platform.

So how to fix my now rogue ItemReceivers.  I could do some fancy coding in Feature activations etc, but I really don’t want to go there and have code left lying about for what will essentially be a one time fix.

To the rescue PowerShell.  Luckily for me we use PowerShell so I  can create a post update installation script that runs just this once.

Here is the gist of it.

###############################################################
# Validate args
###############################################################
    if ($args.Length -ne 1 -or $args[0] -eq "-?")
    {
        Write-Host "Usage: .\FixIt.ps1 <SiteUrl>";
        return;
    }
    $SiteUrl = $args[0];
    cls

###############################################################
#Get Base Objects
###############################################################

    [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
    $site = New-Object Microsoft.SharePoint.SPSite $SiteUrl
    $web = $site.RootWeb
    $lists=$web.Lists

###############################################################
#Change List Event Receivers
###############################################################

$list=$lists["BrokenList"]

#I happen to know there are only 4 Receivers really I should use the count
#One of them is named wrong as well hence the 3 cases
#(in the real version I fixed that too)
#You need to count backwards as it deletes and re-inserts so a foreach wont #work.

for ($i=3;$i -ge 0;$i–)
{
    $er=$list.EventReceivers[$i]
    switch($er.Name)
    {
        "BinaryJam BrokenList Receiver ItemUpdating"
        { 
            $er.Assembly="BinaryJam.MySharePointApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1111111111111111"
            $er.Update()
        }
        "BinaryJam BrokenList Receiver ItemAdded"
        {
            $er.Assembly="BinaryJam.MySharePointApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1111111111111111"
            $er.Update()
        }
        "BinaryJam BrokenList Receiver ItemAdding"
        {
            $er.Assembly="BinaryJam.MySharePointApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1111111111111111"
            $er.Update()
        }
    }
}

$list.Update()

Well what a great gotcha I had today.  I have a WSS application you know custom list templates, event receivers web parts, everything you can think of except workflow.

So I have an upgrade for this, its a new dll and feature files.  I use a build server that can automatically update the AssemblyVersion and automatically edit the dwp aspx ascx files etc to set the version number of the build, its very slick.

Forgetting one thing.  SharePoint has never liked Version numbers. So I applied the update and my webpart fails with safe control errors. 

I forgot when you add the webparts it copies the dwp complete with version number into the content database and I just uninstalled that DLL. DOH! 

After figuring this out with the help of Captain Literal.Net, I stopped my build auto updating the versions and grepping the files etc.  It still marks the file version number to help the support guys but not the AssemblyInfo DLL versions now.

According to the Cap’n its not just the webpart dwp’s but lots of other features (small F)  that don’t like changes to AssemblyVersions, in fact there is code in SharePoint that deliberately IGNORES policy files.

So there you have it, again Versioning is a bit dodge in Scarepoint. Choose when to do it and know what the effects will be.  And don’t forget to take those *’s  (stars) out of the AssemblyVersion attributes and FIX it to 1.0.0.0.

However you can change the Feature.XML file and change the Feature versions this doesn’t have any effect that we have noticed.

Im thinking of throwing together a feature that reads all installed features (hidden or not) and displays the details like title, description and version.