2

I have a strange situation: If the "Require Check Out" and "Create Major Versions" options are switched on for the current Document Library, then when I try to get the CheckOutType property I receive the exception shown below.

item.File.CheckOutType 'item.File.CheckOutType' threw an exception of type 'System.NullReferenceException' Microsoft.SharePoint.SPFile.SPCheckOutType {System.NullReferenceException}

Does anyone know the cause of this issue?

UPD: I use SharePoint 2010, RTM. Here is the code, which cause the exception:

if (item.File.CheckOutType == SPFile.SPCheckOutType.None)
{
//Something else here;
}

And here is Exception StackTrace:

" at Microsoft.SharePoint.Library.SPRequest.GetFileAndFolderProperties(String bstrUrl, String bstrStartUrl, ListDocsFlags ListDocsFlags, Boolean bThrowException, Int32& phrStatus, Object& pvarFiles, Object& pvarDirs, UInt32& pdwNumberOfFiles, UInt32& pdwNumberOfDirs)\r\n at Microsoft.SharePoint.SPWeb.GetFileOrFolderProperties(String strUrl, ListDocsFlags listDocsFlags, Boolean throwException, SPBasePermissions& permMask)\r\n at Microsoft.SharePoint.SPFile.PropertiesCore(Boolean throwException)\r\n at Microsoft.SharePoint.SPFile.get_CheckOutType()\r\n at My Method here " string

3 Answers 3

3

UPDATE

When using SPListItem from a SPQuery, to access .File properties ensure you have fully loaded the item

item = SPList.GetItemById(item.Id)

ORIGINAL (Wrong)

CheckOutType is an enumeration (value type) so can't be null.

http://msdn.microsoft.com/en-us/library/s1ax56ch%28VS.80%29.aspx

My guess is that item.File is null

Try using:

SPFile file = doclib.RootFolder.Files["documentname"]
file.CheckOutType 
16
  • 2
    SPListItem.File and also SPFile.Item often return null in different scenarios. Rather than trying to indirectly retrieve the File or Item object, use the actual getters (if available) or the index enumerators (like in this answer) to get the item. I'll need to do a bit more research to find out why this is, possible deep-deep-deep-dive blog post on this coming up soon.
    – James Love
    Apr 13, 2011 at 10:55
  • @James: Interesting answer
    – Stu Pegg
    Apr 13, 2011 at 11:22
  • I know, right? :P Decided to write that as a comment because it basically reads "Yeah, djeeg is right, because SharePoint is unpredictable at times, let me fire up ILSpy in a couple of days and I'll let you know why".
    – James Love
    Apr 13, 2011 at 11:25
  • SPFile file = doclib.RootFolder.Files["documentname"] - after this code, I recommend you always use if (file.Exists) construction. From my experience, this is a very good practice, really! Apr 13, 2011 at 11:27
  • @MrBubbles: Suddenly I feel you need to post the erroring code and the SharePoint version you're working with, because that error deserves an API dig.
    – Stu Pegg
    Apr 13, 2011 at 12:07
1

You should first check out using a debugger what returns null. From the statement you posted it could be:

  • item is null
  • File is null
  • Inside the implementation of CheckOutType a nullreference is throw.

Use a debugger to figure this out.

3
  • You dont need the debugger to trace the error; item.File is not null because otherwise the message would be 'item.File' threw an exception..., CheckOutType is not null because it is an enumeration
    – djeeg
    Apr 13, 2011 at 11:05
  • 2
    @djeeg: SPFile.CheckOutType is a property, which may be doing further work to return the enumerated value; thus the exception could be raised there. SPCheckOutType is the enumeration (the type of the property).
    – Stu Pegg
    Apr 13, 2011 at 11:42
  • ... ah yes, true
    – djeeg
    Apr 13, 2011 at 12:11
1

We have a similar problem that we figured out.

When we call:

SPList list = web.GetListFromUrl(...)
foreach(SPItem item in list.Items)
{
  if (item.File.CheckOutType == SPFile.SPCheckOutType.None)
  {
   //Something else here;
  }
}

in rare cases and for a specific item id (lets say item id = 524) the code will always run into a deadlock. It means the program will hang at the call of

  item.File.CheckOutType

It will not return, not throw an exception and will never timeout. You can run the code as often as you want, it would always hang on this item id 524.

When we call this via rootfolder (calling the file of the trouble causing item id):

SPList List = web.GetListFromUrl(...)
SPFolder Folder = List.RootFolder;
foreach(SPfile File in Folder.Files)
{
  if (File.CheckOutType == SPFile.SPCheckOutType.None)
  {
     //Something else here;
  }
}

it will work. Same with Item.File.length and File.Length. But: Item.File.Name will work.

Interesting thing: If you identify such a trouble causing item and make a check out and check in from inside the browser, it looks like something is cleaned up and also the loop through this List.Items will work (till another item might cause the problem).

I have heared something about that this is because Files and Items are managed separatly (SPRootFolder and SPList) and that in rare cases the reference of the file in the Item is not loaded correctly or might get lost.

So you have more information on this? Or does anyone else noticed a simlar problem?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.