2
Vote

SPSource List Schema never generates BaseViewID=0 + OOB Content Type Issues

description

PLEASE HELP ME UNDERSTAND THIS, and please provide an affirmation or workaround to what I'm about to point out.
 
If I create a list based on an existing template such as a Calendar, Task, Picture Library, you name it - and add/remove/edit fields without actually creating a content type (I just want to generate a schema.xml to use) then SPSource runs and creates a list that is essentially an "Unusable Dead End"
 
What I mean by this, is that when you run SPSource to generate the list schemas and feature for lists that do not have custom content types, the tool creates a list definition that when deployed will use its own crazy content type as opposed to the original OOB content type. Example ensues:
 
1) create a calendar list, and add a few columns at the list level, maybe play with the view a bit to customize the list
2) run spsource as directed to generate a list definition for this customized calendar
3) deploy the list definition for this calendar
 
Observe that the new list "appears" to be the same and "appears" to have saved you time by creating all the xml you need. However all items you enter in this generated calendar will not be of type "Calendar Item" so you will not be able to roll up the generated list contents via CQWP or any other programmatic approach that checks for the list to be of Calendar type. Instead a new content type is assigned to the generated list of type "List Name" which inherits from the System content type (not even the Item content type).
 
There are several other issues like not generating a BaseViewID="0" for each list definition the tool creates, which renders them unable to be used as list view web parts.
 
I am very sad to have trusted this tool because it has a lot of potential, and yet it totally screwed me over at the last minute while using it to generate list definitions for my current project.
I cannot complain much more given the tool is free, but these issues I point out are show-stoppers and in my case made me lose a lot of time - roughly 2 weeks worth - of unusable code I had to scrap.

file attachments

comments

jthake wrote Jan 14, 2010 at 7:40 AM

I really appreciate your feedback on this around content types and baseviewID's. I was not aware of this issue, and this may only be the case with Calendar lists...I will have to confirm. i have already blocked the tool from being used with Picture Libraries and Wiki's as these are so far away from the standard logic of a list. VSeWSS Solution Generator will not create them for you either. Maybe Calendar is the same.

It sounds like you have enough knowledge of the schema to be able to edit the schema.xml manually. You could just remove the ContentType elements in the schema.xml and replace these with the out of the box ContentType ones. Same applies for editing the BaseViewID's. Unless ofcourse you've deployed these to Production already and have instances live. In that case I'd deploy new ListTemplates, create list instances off these and then simply move the data between them programmatically.

Again, I do apologies for the inconvenience here. When I get in from work tonight, I'll take a look at this scenario and report back to you on my findings on why it creates a new Content Type and not just reuses the base ones.

jthake wrote Jan 14, 2010 at 10:02 AM

OK i've had a chance to look at what is generated from a 'Calendar list' which is an Event ListTemplate seen here:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\EventsList\Events

The code is extremely similar although the ContentTypeRef element is not in the SPSource generated one.

I can also confirm that yes it does appear to associate a different ContentType for each SPListItem that is created on that ListInstance. I will need to confirm that maybe the ommission of the ContentTypeRef element is doing this as it explicitly creates that content type Id.

I can confirm that it is not generating a BaseViewID=0. I will check the logic here on this issue.

For my own reference, PowerShell script to report on ContentType of items created in dev and staging:

$12HivesDir = "${env:CommonProgramFiles}\Microsoft Shared\web server extensions\12\"

returns the SPSite object from the specified URL

function get-spweb ([String]$webUrl=$(throw 'Parameter -webUrl is missing!'))
{
$site = New-Object -TypeName "Microsoft.SharePoint.SPSite" -ArgumentList "$webUrl";
return $site.OpenWeb();
}

$web = get-spweb "http://demo/sites/devsite/" $web.Lists["Events"].get_items()[0].ContentType | ft Id


$web = get-spweb "http://demo/sites/stagingsite/" $web.Lists["Events"].get_items()[0].ContentType | ft Id

jthake wrote Jan 14, 2010 at 12:29 PM

OK after testing making the ContentTypeRef element be included I can confirm that fixes the content type of the list items. Even though content types are not enabled it looks like it requires this for some reason?!? Some List Template Schema files in 12 hive do not have this element.

Interestingly if you use the object model to explore a Events List instance and do SPList.Views only 3 views come up although the schema.xml file has 4!?! I'll have to look into that further...

wrote Jan 14, 2010 at 1:39 PM

wrote Jan 14, 2010 at 1:47 PM

talarico wrote Jan 14, 2010 at 2:07 PM

I renamed the title of this reported issue as it is more pressing and more spread than just to the Events list schema.
I am unfortunate enough to have deployed broken code, so the tool generated more work for me than it saved me. But should this be resolved, and the project continue to grow - I would certainly be grateful for this tool. Currently though, I would warn downloaders/users that this tool in its current release may be more hassle than it's worth IMO.

jthake wrote Jan 14, 2010 at 11:55 PM

Mate did you see that I've actually released a new version that fixes this issue now? I spent 3 hours on it last night.

wrote Feb 10, 2010 at 9:30 PM

panoone wrote Oct 5, 2011 at 10:52 PM

Hi Jeremey, I can confirm ( using 1.1.1.0) that the BaseViewID issue is not restricted to Calendar lists. Having finally identified the problem I was able to manually modify the schema.xml but it's not a walk in the park! :)

I downloaded 1.2.0 and noticed that SPSource.exe still shows a version of 1.1.1.0 and the same modification date I previously had installed. Is this the latest release?

panoone wrote Oct 6, 2011 at 2:17 AM

For anyone else who hits the same issue and wants to use their list as a List View Web Part, perform the following steps.
  • Open schema.xml and locate the AllItems view (NB: this should never be deleted).
  • Change the BaseViewId to 0 (it's probably at 1).
Additionally, I've you've specified a custom list form as the default view, you can also run into trouble with moving content via the Content and Structure tool. If in doubt, keep the default view.

wrote Oct 6, 2011 at 11:24 PM

panoone wrote Oct 6, 2011 at 11:24 PM

Hi Jeremy, I've performed a few more tests and am providing some screenshots to better explain the problem with list content types.

I've compared the XML between the src and dest in SharePoint Manager and with the exception of the list CT there is no difference at all. Yet the list CT on the destination list contains no data when viewed through the UI. [attach1.png]

Despite this, the DispForm still displays the correct order and required fields made in my original modifications. [attach2.png]

However the Context and Structure tool is unable to move/copy items from dest->src and throws a lengthy but meaningless error. Neither could I copy/paste items via Explorer view. Refreshing the list in the UI displayed no items. What's odd is that I could Upload Multiple items from src->dest via Office Picture Manager.

Adding the Unknown Content Type to the dest list resolved the problem with Content and Structure but also did something very interesting to the Picture content type. The DispForm for this CT now displays nothing but a Content Type dropdown. [attach3.png]

I'm wondering if the list content type ID, or version params in the XML are causing these problems, or if SharePoint is storing additional info somewhere else.

As a last curiosity, when activating the list feature, the logs show the following while creating the list instance. Not sure if this is in any way relevant.
  • Creating list "Image Gallery" in web "http:..." at URL "/ImageGallery", (setuppath: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\ImageGallery\ImageGallery")
  • Failed to find generic XML file at "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\xml\onet.xml", falling back to global site definition.
Thanks for a great product and hope this helps some!

panoone wrote Oct 7, 2011 at 2:04 AM

OK, OK. Adding the contenttyperef for Unknown Document Type to the source still breaks Content And Structure. :\

Here's the error as it appears in sitemanager.aspx which definitely points to a content type issue.

<error><message>Cannot complete this action. Please try again.</message><full>Microsoft.SharePoint.SPException: Cannot complete this action. Please try again. ---> Microsoft.SharePoint.SPException: Cannot complete this action. Please try again. ---> System.Runtime.InteropServices.COMException (0x80004005): Cannot complete this action. Please try again. at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateField(String bstrUrl, String bstrListName, String bstrXML) at Microsoft.SharePoint.Library.SPRequest.UpdateField(String bstrUrl, String bstrListName, String bstrXML) --- End of inner exception stack trace --- at Microsoft.SharePoint.Library.SPRequest.UpdateField(String bstrUrl, String bstrListName, String bstrXML) at Microsoft.SharePoint.SPField.set_SchemaXml(String value) at Microsoft.SharePoint.Deployment.ContentTypeSerializer.UpdateContentTypeFields(SPContentType sourceContentType, SPContentType targetContentType, String contentTypeXml, ImportObjectManager importObjectManager) at Microsoft.SharePoint.Deployment.ContentTypeSerializer.UpdateContentType(SPContentType sourceContentType, SPContentType targetContentType, String contentTypeXml, ImportObjectManager importObjectManager) at Microsoft.SharePoint.Deployment.ContentTypeSerializer.ProcessContentType(SPContentType sourceContentType, String contentTypeXml, ImportObjectManager importObjectManager, Boolean IsParentSystemObject) at Microsoft.SharePoint.Deployment.ContentTypeSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector) at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObject(Type objectType, Boolean isChildObject) at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope) at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader) at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects() at Microsoft.SharePoint.Deployment.SPImport.Run() at Microsoft.SharePoint.Publishing.Internal.DeploymentWrapper.Copy(String[] sourceSmtObjectIds, String destSmtObjectId) --- End of inner exception stack trace --- at Microsoft.SharePoint.Publishing.Internal.DeploymentWrapper.Copy(String[] sourceSmtObjectIds, String destSmtObjectId) at Microsoft.SharePoint.Publishing.Internal.WebControls.CopyObjects.Copy()</full><customData>Operation to Copy 'All selected items' to '/ImageGallery' Failed</customData></error>

wrote Feb 13, 2013 at 10:18 PM