Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Anyone who has experience with programmaticly 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 programmaticly". Believe me, we have our reasons to do so. If necessary I would love to explain this. But atm 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)
                {
                    if(!version.IsCurrentVersion)
                    {
                        version.Properties["vti_title"] = "TESTTITLE";
                    }
                }
                oItem.Update();
            }
        }

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

Thanks

Edit:

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 alot 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: http://i40.tinypic.com/jaf3fb.png , document after move: http://i40.tinypic.com/e5qkx1.png).

So to fix this, I would like to modify each version serperatly and set the correct version metadata as was visible before the move. If you use the default SPFile.MoveTo this version metadata is lost aswell. 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)

share|improve this question
    
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 '12 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) –  Frederik P. Apr 20 '12 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 '12 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... –  Frederik P. Apr 22 '12 at 21:42
    
Ah ok. Then I don't think I can help you any further, sorry. –  Jasper Apr 24 '12 at 6:02
show 3 more comments

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.

BUT ONLY USE IT IF YOU'RE BEAKING THE LAW BY NOT DOING IT

share|improve this answer
    
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. –  Frederik P. Sep 5 '12 at 6:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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