I have been developing a solution for a client that involves the following lines of code, to create a new file inside a document library:

metadata["SomeField"] = someFieldValue;
metadata["Title"] = documentTitleValue;
var filePath= Guid.NewGuid().ToString("N") + ".docx";
var file = pastaEdicao.Files.Add(filePath, fileContent, metadata, false);
var newItem= file.Item;

The code works, or has worked for a few weeks. This project is being developed as a side project for a larger solution that was assigned to another company.

I have linked the callout menu to the Title column and thus the users interact with the files through the document titles as opposed to the file name. At the end of a workflow the file is assigned a proper name and the change is seamless to users.

A recent 'something' slowly made this code stop working in the testing and pre-production servers. It still works in production and in the development server (which only I use and does not have any part of the other company's solution).

First it happened in the test server, new files stopped having their title set, whilst the rest of the metadata were filled in correctly.

A few days later this behavior was replicated to the pre production server. It has yet to reach production, but I fear that it's a matter of time.

I have not made any changes to the file creation process since it was deployed to any of the servers (and am the only person working on this part of the project).

The fact that it started in an environment and then made its way into another makes me think of it being caused by something deployed by the other consulting company as part of their solution. Everyone has said that there were no changes during the specified period (who are they kidding? - happened near xmas and new years narrowed down to a 2 hour period)

I am honestly stumped and don't know what else to look into. Does anyone have any idea what might have been done to break this?


  • I am using the HashTable overload of the method to avoid conflicting with the workflow, that starts on file creation and sets the status column. If I update the Title field of the new item after creating it, the workflow crashes due to update conflict.

  • I noticed through a remote debug session that the information is part of the SPFile.ListItemAllFields.Xml properties, but for some reason it is not being mapped to the title. The values are set as " Title:SW|Durp".

  • It is a multi-lingual server and I have tried variations of the Title column (went as far as adding all of them). I have not tried SPBuiltinFieldID.Title since the hashtable takes only strings as keys.

  • Through the interface, the Title column does not appear to have been renamed.

  • The Title field can be updated manually afterwords and all works great.

  • I am bullheaded about making too drastic changes to the code without understanding why this is happening ._.

  • Just to let you know, I copied your code and run on a plain site, fresh library, and the title got filled. Just one thing that may give you some clue: Turn on versioning on the library. I have a feeling that something is changing the title after it is first created. That way you may be able to track. P.S: I totally relate to your bullheadedness! Jan 9, 2015 at 0:08
  • Thanks for the attempt! I deleted the library in one of the servers and it went back to working, I still don't know why it stopped. Bullheadedness for good reasons wins....will check versioning. I do have it active - and I have checked the event receivers attached to the list and they are all native.
    – Choggo
    Jan 9, 2015 at 1:50
  • did you try using vti_title instead of Title?
    – gdbdable
    Apr 7, 2015 at 19:20
  • I'm out of this project now, but I'll forward the suggestion to the person that took it over. Deleting the list and recreating it, solved the problem, somewhat.
    – Choggo
    Apr 7, 2015 at 23:42

1 Answer 1


Check this link:


It just has solved the same problem for me. Basically it says that you have to use vti_title as name of the field, or use Item.Title property. About why it changed, I have no idea, maybe it was a SharePoint update or something.

  • I guess I should've tried the UID then :)
    – Choggo
    Feb 2, 2016 at 12:36

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.