Anyone who has experience with programmatically updating the SPFileVersion.Properties Hashtable?

I have a special situation where I would like to modify this Hashtable. Most of you will say: "Why on earth would you ever want to change this programmatically". Believe me, we have our reasons to do so. If necessary I would love to explain this. But at the moment this has nothing to do with the problem.

I am using this code, but it does not change anything in the "Version History" in the UI.

I've tried several things, I'll just show some easy lines of code which do not work at all:

using (SPSite oSite = new SPSite("[MY URL]"))
            using (SPWeb oWeb = oSite.OpenWeb())
                SPList oList = oWeb.Lists["Documents 2"];
                SPListItem oItem = oList.Items.GetItemById(23);

                foreach (SPFileVersion version in oItem.File.Versions)
                        version.Properties["vti_title"] = "TESTTITLE";

So the above code is not doing anything, I've put a "watch" on version.Properties["vti_title"] and this watch does change to the new value. But it does not get saved to SharePoint ?

I've used Update, SystemUpdate, UpdateOverwriteVersion, SPFile.Update



Why I want to do this:

The fact is I have created a copy/move custom workflow activity which copies or moves files in the entire farm. This also works with RMS protected libraries. It's a "hack" to get documents out of RMS. This was required by the customer for a "read/edit area concept".

Copying files out of libraries with RMS enabled can cause a lot of issues because it is simply not supported. But I managed to get around all these issues, only one problem stays: After MOVING (so move, not copy) a file in the farm, the version histories metadata is lost. (only the current versions metadata is shown) (original document, document after move).

So to fix this, I would like to modify each version separately and set the correct version metadata as was visible before the move. If you use the default SPFile.MoveTo this version metadata is lost as well. The only way to get what I want is to move the file using "Manage content and structure"... (this uses SPExport/SPImport, which I am not allowed to use + SPExport/SPImport does not work with RMS enabled libraries)

  • I'm interested in the reasons why you would want to, even if you say you really need to. Perhaps there's a different technical solution to your functional question.
    – Jasper
    Apr 19, 2012 at 15:36
  • Jasper, I have edited my post and explained it at the bottom of the post (including 2 pictures of an example). BTW: copying eacht version seperatly does not work because of the RMS. (for none RMS libraries we could use this fix as mentioned on the internet) Apr 20, 2012 at 14:11
  • Ok. I'm not that into RMS so I don't think I'll be able to solve your problem. But here's a thought which might help. If you can use SPFileVersion to get an old version of the file, would it be possible to move that one first and then overwrite it with the next version and so on? Perhaps that would rebuild the history.
    – Jasper
    Apr 22, 2012 at 9:36
  • Jasper, that is exactly what is possible without RMS. But to bypass these RMS security, I am using a mechanism which does not allow me to copy each version seperatly. What u are saying is a solution mentioned on different blog posts. But they all use it without RMS. Their solution is great, but because what we are doing (bypassing the RMS) is not how sharepoint is designed we cannot use this... Apr 22, 2012 at 21:42
  • Ah ok. Then I don't think I can help you any further, sorry.
    – Jasper
    Apr 24, 2012 at 6:02

1 Answer 1


The version history is readonly.

For SharePoint 2007 I made a hack, which will cause your SharePoint Farm to be unsupported, but if you have legal requirements to fix something that might be your only option.


  • Hi, sorry for the very very late response. This was a low priority issue. Does this hack give me the possibility to copy seperate versions. I do not simply want to modify the checkin comments. The problem is that while doing a move from RMS library to NON RMS library (which is not supported normally) I lose all my version history. All metadata is merged into 1 version (like a copy). But we do not want this. Sep 5, 2012 at 6:42

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.