Working on a project recently, we’re provisioning about 15 list templates as part of our SharePoint publishing solution.  There had been a mix-up with the “Type” Id used for the ListTemplates within the XML definition – can you spot a mistake ?

<List xmlns="http://schemas.microsoft.com/sharepoint/" BaseType="0" DefaultItemOpen="0" Direction="none" DisableAttachments="False" DraftVersionVisibility="0" EnableContentTypes="True" FolderCreation="True" Name="Comments" OrderedList="False" QuickLaunchUrl="False" Title="Comments" Type="113" VersioningEnabled="False" Url="Lists/Comments" Id="e3183ba9-0b61-42dd-8ff8-f12eb3bc2d62">

We had inadvertently ‘overwritten’ some of the OOTB SharePoint list templates.  Not actually written over the files on disk, but hi-jacking the Types – from 100, 101, 102 – up to 115 – and we had a multitude of problems.

One of the worst culprits had a symptom of the “Add Web Part page” being empty – none of our custom webparts were listed. 

And it turned out we had a List Template with the same TypeId as the “Web Part Gallery” – yikes.

This post details all the SharePoint base List Type Id’s – and made us realise what we needed to fix – the lesson is “avoid these numbers”.

We’d eradicated most of our problems by changing the TypeId’s in the feature.xml – starting at 1000, and deleting / re-activating, etc – but one problem remained.

Within the ‘Create List’ page, there is no “CUSTOM LIST” shown.   This is kinda bad don’t you think !?  

Has document libraries, etc – just not the normal “title only” custom list.   Dammit.

We found a way to ‘bring it back’ – from a look at another dev machine, which HAS the Custom List.

When hovering over the list template :

Have a look at the URL :

The FeatureId corresponds to the list template that can be found in the following directory :

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEFEATURESCustomListFeature.xml

And – if we look at the Element Manifest :

You can see – there’s the Type=100 list, and whoops – we’d overwritten it.

So – because it’s actually just a feature, we just thought “I wonder if we could just re-activate it ??!”

Here’s the command we tried :

stsadm -o activatefeature -id 00BFEA71-DE22-43B2-A848-C05709900100  -url http://servername –force

And yep – the custom list is back !    *phew*

Hopefully that’s a useful tip for some folk. 

Of course, the best option is NOT to have ListTemplate’s with overlapping Type’s (with SharePoint OOTB ones).

🙂

I was using a codeplex tool (SPSource) to generate the feature/s – this was acknowledged as a bug, and is to be fixed in the next release (soon)