Fixing 'Feature {Guid} for list template is not installed in this farm. The operation could not be completed'

By Pako Simeonov

"Feature {Guid} for list template is not installed in this farm. The operation could not be completed." Probably this is the message that I get the most when I'm developing a project that has a high usage of list created from list templates. You can find useful one of my previous articles on that topic - How to create List Templates and List Instances with VSeWSS 1.3

Here is a screenshot of a message that that I got recently and it happened just after I deployed a SharePoint solution using the VSeWSS 1.3 that had couple of content types, list templates and list instances.

Although the message is about a list template not being installed you can pretty quickly guess that the problem is the list instance that is using the list template since actually the message was shown when you tried to open the list itself. My first reaction was to check the SharePoint FEATURES folder (%Program Files%\Microsoft Shared\Web Server Extensions\12\Features ) for a feature with that Guid and as I expected I couldn't find anything there that matches the identifier from the error message. The hardest part is to find a starting point for the troubleshooting which can give us some directions to what to look for and in this case since the problem is in the list instance the most obvious thing is to actually see what kind of properties SharePoint has for this particular list and is there a one that has something to do with the Guid.

Using one of my favorite tools (SharePoint Manager 2007) that helps me a lot during the troubleshooting of all the problems I face during my SharePoint development it is pretty easy to quickly check all the properties that a list has. Luckily enough for me I found what I was looking for and right away had the idea what is wrong and what is causing the error. The field that contained the Guid from the error message was a value of the TemplateFeatureId list property. So here is a quick explanation of what actually happened:

During the deployment of a feature using the VSeWSS 1.3 the old one is being retracted and thus the feature files are being removed from the 12 Hive folder of SharePoint and meanwhile a new Guid is being generated by SharePoint internally which is then being used instead of the fake one in the schema.xml, listdefinition.xml and instance.xml files in your Visual Studio .NET project. Even when you open the instance.xml file you can see a message there saying the following:

The following Guid for FeatureId is used as a reference to the list definition, and it will be automatically replaced with actual feature id at deployment time.

So now we have the TemplateFeatureId of the list instance the same as the list template one. During a new deployment of the list template if there is already an existing list instance it is being preserved and no new one is being created, which is pretty much expected since we don't want to loose our already existing list with all its data just because we redeployed the list template. So what happens is that the list template feature that the list instance is pointing to is being replaced by the new one which has a new FeatureId generated by SharePoint, but the TemplateFeatureId of all the list instances that are instantiated from the list templates remain the same and thus when the list is being opened no such list template is being found and the exception thrown by SharePoint finally makes sense.

From the problem description above the solution seems to be pretty easy. We just need to change the TemplateFeatureId to the Guid of the newly deployed list template. The problem here is how do we map the old list template to the new one that was deployed. Of course for a man this is easy since we can quickly find the folder of the feature, take a look at the new Guid in the feature.xml and then change the TemplateFeatureId of the list, but we don't want to do that every single time we deploy our solution to SharePoint which can be pretty often during the development phase. The question here is can we automate this process, so the problem can be fixed just by clicking a button? The answer is Yes, we can automate the process and make it work in most of the cases. I've created a pretty convenient tool called List Instances Fix Tool that you can download from www.myitechnology.com

When you run it on the SharePoint server it will give you a list with all the Web Applications and their site collections that exist in the SharePoint Farm. You can easily see if there are bad list instances in a site by expanding the site collection. The tool will give you the total number of lists in this site and the count of the bad ones along with an exclamation icon if there is at least one bad one. Once you click on the site a list with all the bad list instances will be presented. The tool will try to guess which is the right list template, but if it can not do that you still have the option to select it manually from all the available list templates - activated or not.

I've also published the tool in codeplex - ListInstanceFix 1.0