tags:

views:

81

answers:

2

I have a feature that provisions a heap of files including layouts and images into a MOSS site. Over the lifetime of this site we have altered the provisioning file, the Elements manifest, a number of times: adding files, removing files, and changing the file structure in the feature folder. Unfortunately we have discovered that if you remove a file from a provisioning document then reactivate the feature the SPFile of the removed file remains in the content database.

Since these files are ghostable they have a property in the sharepoint content db called 'SetupPath', which is basically the Template folder relative path of the original file. This file is presumably used when the file is in its unghosted state. Since I have changed my feature this setup path refers to a file that doesnt exist.

The ramifications are: I cant update the file in the API any longer, It doesnt appear via the GUI and when I run a content deployment, a full content deployment, I get file not found errors. Worse, given there is a good 1000 of these files that have been removed, there are something like 3.5k errors on every full content deployment. The push doesn't stop, but so many errors are disconcerting and hide any actual catastrophic errors should they occur.

Finally if I update a file, giving it a new path, then when that file is referenced in sharepoint a 404 is thrown. Super bad if the file happens to be a layout (all pages using it fail).

I've coded up code to delete SPFiles that have are no longer provisioned, problem solved. However files that are still being used but just have an incorrect setup path, I am at a lost.

I can go SPFile.Properties["vti_setuppath"] and see the incorrect setup path. However, though I can set this property I cannot seem to make it stick. SPFile.Update() doesnt work, and neither does checking the file in and out.

Any help would be appreciated.

A: 

There is an workaround that you can try. Now that you have finalized the path of the Layout Pages. You can create a new Page Layout with the path you want and call it version 2, deploy it and in SharePoint you can change the Page layout of the Instance Pages. Now you can remove all the Old Page Layouts.

Kusek
So I could provision a new layout then programmatically switch all using pages to this layout. THat would fix the problem of simply deleting and reprovisioning the layouts, but would force me to have a new name for the new layout, which would be a pain. I suppose I could then reverse the process, reprovisioning the original layout and switching the pages back, but its still not the most elegant process I could think of. Cheers.
Aquinas
After finding my self making unmanaged calls to OWSSVR.dll, I have decided that above is the best answer at the moment. Heres hoping this is more flexible in 2010!
Aquinas
A: 

The fix is to upload/provision a new file, and then use SPFile.MoveTo to override the original file. This preserves the provisioning and preserves all links to this layout without having to modify any structure beyond the layout itself. It is also probably as elegant as I can hope for.

Aquinas