SharePoint | Value cannot be null, parameter name: g
Problem:
Moving documents in SharePoint can be a difficult task at times.
One of the biggest challenges is keeping previous document versions.
In some cases, it works if you simply move the documents from one place to the other, while using explorer views (nb: only works for MOVE operation, not for COPY).
In other cases, explorer view, site content and structure and even 3rd party tools will fail to accomplish this.
One of the reasons - and the one explained in this post - is a problematic field schema. More specifically, the lack of a certain attribute on a certain type of field, that will prevent the operation from running successfully, resulting in screens such as the ones below.
Solution:
In this case, it appears that we have a field with type "User", which does NOT have the attribute "List" set to "UserInfo", which seems to be a must.
Although we might not have problems adding and editing documents without this attribute, we will definitely have problems with migrations, import/export, etc., in the future.
To solve this, I have a script with two steps.
1) identify fields of type "User" in the document library
The script outputs four entries or fields. three of them are internal fields, and one is our custom field.
2) Add the missing attribute (SPField.SetAttribute)
Complete source code here
Related links
http://sharepoint.stackexchange.com/questions/62731/move-publishing-site-between-subsites-using-manage-content-and-structure
http://blog.jussipalo.com/2009/06/moss-unable-to-import-custom-spfields.html
Moving documents in SharePoint can be a difficult task at times.
One of the biggest challenges is keeping previous document versions.
In some cases, it works if you simply move the documents from one place to the other, while using explorer views (nb: only works for MOVE operation, not for COPY).
In other cases, explorer view, site content and structure and even 3rd party tools will fail to accomplish this.
One of the reasons - and the one explained in this post - is a problematic field schema. More specifically, the lack of a certain attribute on a certain type of field, that will prevent the operation from running successfully, resulting in screens such as the ones below.
http://.../Demo Document 001.docx: Value cannot be null. Parameter name: g
Solution:
In this case, it appears that we have a field with type "User", which does NOT have the attribute "List" set to "UserInfo", which seems to be a must.
Although we might not have problems adding and editing documents without this attribute, we will definitely have problems with migrations, import/export, etc., in the future.
To solve this, I have a script with two steps.
1) identify fields of type "User" in the document library
The script outputs four entries or fields. three of them are internal fields, and one is our custom field.
function PrintFields($web, $listName) { $lib = $web.Lists.TryGetList($listName) if($lib -eq $null) { throw "List $listName does not exist!" } Write-Warning "Displaying User fields for list $listName" write-host "" $lib.Fields | where-object {$_.Type -eq "User"} | select InternalName, Type, SchemaXml | format-list }
2) Add the missing attribute (SPField.SetAttribute)
function EditFieldXML($lib, $targetField) { try { $fld = $lib.Fields.GetFieldByInternalName($targetField) } catch { write-warning "Field $targetField does not exist!" write-host "" return } Write-Host Current field definition $fld.SchemaXml write-host $newLine $fld.Sealed = $false $fld.PushChangesToLists = $true $fld.Update() $schema = [xml]$fld.SchemaXml $schema.Field.SetAttribute("List","UserInfo") $fld.SchemaXml = $schema.PSBase.OuterXml $fld.PushChangesToLists = $true $fld.Update() Write-Host New Field definition $fld.SchemaXml }
Complete source code here
Related links
http://sharepoint.stackexchange.com/questions/62731/move-publishing-site-between-subsites-using-manage-content-and-structure
http://blog.jussipalo.com/2009/06/moss-unable-to-import-custom-spfields.html
Comments
Post a Comment