Import complains of null Guid

Apr 14, 2009 at 2:32 PM
Hi Chris

This looks like a really useful tool. I've been trying out v1.1 to move some documents around. I first copied a handful of documents around within a site collection and had no problem. I'm now trying to copy a larger document library, including folders, from one SharePoint farm to another. According to the import log it imports all of the files OK, but when it then goes to import the list items which contain the files it fails. Have you seen this error before?

[14/04/2009 12:22:51]: Progress: Importing ListItem /schoolpersonnel/Documents?id=5.
[14/04/2009 12:22:52]: Progress: Importing ListItem /schoolpersonnel/Documents?id=6.
[14/04/2009 12:22:52]: Progress: Importing ListItem /schoolpersonnel/Documents?id=371.
[14/04/2009 12:22:53]: Progress: Importing ListItem /schoolpersonnel/Documents?id=340.
[14/04/2009 12:22:54]: Progress: Importing ListItem /schoolpersonnel/Documents?id=308.
[14/04/2009 12:22:55]: Progress: Importing ListItem /schoolpersonnel/Documents?id=341.
[14/04/2009 12:22:55]: FatalError: Value cannot be null.
Parameter name: g
   at System.Guid..ctor(String g)
   at Microsoft.SharePoint.Deployment.ListItemSerializer.UpdateFieldData(SPListItem listItem, ImportObjectManager objectManager, Guid docId, String fieldName, String value, String value2, Guid gFieldId, Boolean& bCreated, Dictionary`2 brokenFields)
   at Microsoft.SharePoint.Deployment.ListItemSerializer.UpdateFieldData(SPListItem listItem, Guid docId, Boolean& bCreated, SPContentTypeId contentTypeId, ImportObjectManager objectManager, Object data)
   at Microsoft.SharePoint.Deployment.ListItemSerializer.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()

If I can get past this I'd like to try out your new beta version, because the scenario we're looking at using this for is for a regular scheduled copy of documents from one site collection into another.
Apr 16, 2009 at 8:09 AM
Hi Caterwomtious,

Hmm, I've not seen this exact error before, but a bit of Googling finds a few folks hitting it when doing an STSADM import (does same thing as Wizard import underneath). My suspicion from these posts is that the problem is something to do with lookup fields. Two questions:

  • Are there any lookup lists which aren't being deployed in the same package? (Perhaps they're in another web or you're deploying only a document library?)
  • Do you have SP1 + Infrastructure Update? (I think of these as the minimum baseline required for successful Content Deployment since MS fixed lots of issues in these)

Thanks,

Chris.

Mar 12, 2010 at 4:12 PM

Hi Chris

Sorry, this project went cold for a while but I'm back on it now. I'm still getting the error and I think I've narrowed it down to a UserMulti field which is part of the content type the test document is using.

When there's a value in the UserMulti field, I get the error. When the field is empty, there's no error. The UserMulti field is included in a content type as an optional field, and it's defined like this:

<Field ID="{3DB4F927-EA0C-4c16-91F1-2D2059749E31}"
         Name="Egms_Creator"
         DisplayName="Contact for staff"
         Description="People or groups responsible for the content"
         StaticName="Egms_Creator"
         Group="e-GMS columns"
         BaseType="Text"
         Type="UserMulti"
         Sealed="TRUE"
         ShowInDisplayForm="FALSE"
         ShowInEditForm="TRUE"
         ShowInNewForm="TRUE"
         ShowInListSettings="TRUE"
         UserSelectionMode="1"
         Mult="TRUE"
         SourceID="http://schemas.microsoft.com/sharepoint/v3"/>

All of our machines are running on MOSS 2007 SP2 with the April 09 Cumulative Update.

Any ideas? Is this simply a bug I need to log with Microsoft?

Mar 12, 2010 at 4:40 PM

@caterwomtious,

Yes, I think this is potentially a bug to be raised with MS. What would be an interesting test is to try importing the .cmp with STSADM import - you'll lose the ability to retain IDs but this might not be needed in your scenario anyway. Then if you still have the problem, it's a strong case to take to MS as there would be zero custom code operating.

Regardless, since the Content Deployment Wizard only uses supported API methods and I don't think it's a Wizard issue anyway, I'd be inclined to raise a support call.

HTH,

Chris.

Mar 15, 2010 at 1:37 PM

Thanks Chris. I'll try to put together a minimal test case with a content type that inherits from Document and adds just a UserMulti field, and see what happens with the stsadm commands.

Mar 15, 2010 at 3:50 PM

The import failed with the same error, so that confirms it's an issue we'll need to take to MS. Thanks for your help Chris.

 

Mar 23, 2010 at 2:45 PM

It turns out the field XML was wrong. The XML which works for a multiple-user field which accepts people and groups is:

     <Field ID="{guid}"

            Type="UserMulti"

            DisplayName="UserMulti field"

            Name="UserMulti_Example"

            List="UserInfo"

            StaticName="UserMulti_Example"

            Group="Testing"

            ShowField="ImnName"

            UserSelectionMode="1"

            UserSelectionScope="0"

            Mult="TRUE"

            Sortable="FALSE"

            />

 When moving content between site collections it’s important to use the “-includeusersecurity” switch on stsadm/setting in the wizard, because otherwise it only transfers the IDs of the users in SharePoint, and in another site collection that ID will usually refer to a different person.

Jun 24, 2011 at 2:21 PM

Combining the lists that have lookup fields in 1 package solved my problem for the moment.

Thanks Chris for your feedback.

Mar 18, 2013 at 9:28 AM
It appears that all user fields (multi and single) create this problem if they were created without the List="UserInfo" property. The import/export API probably treats them like normal lookup fields.

So if you have already created some fields without the property the solutions is:
  1. Add the property to your caml for the field.
  2. Push updates to that field down using the UI or code.