IgnoreIfAlreadyExists

Recognize this attribute of the Elements/Module/File element? If you’ve tried to write a feature that provisions a file to a document library, maybe you’ve stumbled across this one. Here’s the official Microsoft documentation is on this attribute:

IgnoreIfAlreadyExists

Optional Boolean. TRUE to provision the view even if the file aready exists at the specified URL; otherwise, FALSE.

Ok, everybody got that? And yes, it really says “aready”.

Now, I don’t know about you, but I read that, and I’m thinking that I can use my feature to overwrite an existing file by simply setting IgnoreIfAlreadyExists to True. Ahhh, if it were that easy, I wouldn’t be writing about it.

What this attribute really does is represented by the following pseudocode:

if (FileExist(fileToProvision)){ 
 if (IgnoreIfAlreadyExists == TRUE) { 
   ; // do nothing 
 } 
 else { 
   throw new Exception(“File Exists!”); 
 } 
} 
else { 
  ProvisionTheFile(fileToProvision); 
}

That’s right. Disregard the documentation, the true way that IgnoreIfAlreadyExists work is it ignores the issue if the file already exists. Useful, right? You’re already thinking how you can put this to use in all your features, right? Sure you are.

So now the question becomes, what kind of voodoo magic is available in SharePoint that allows you to overwrite a previously existing file? If you find it, let me know, because the Google doesn’t have the answer, and neither do I. The best I can offer is to set up a feature receiver and implement FeatureDeactivating to delete your custom file on deactivation:

// delete file in a document library so it can 
// be updated with a new version of the feature
using (SPWeb web = properties.Feature.Parent as SPWeb){ 
  SPList myDocLib = web.Lists["DocLibName"]; 
  if (myDocLib != null) 
  { 
    SPListItemCollection items = myDocLib.Items; 

    for (int i = items.Count - 1; i >= 0; i—) 
    { 
      SPListItem item = items[i]; 
      if (item.Name == "filetodelete") 
      { 
        items[i].Delete(); 
      } 
    } 
  } 
} 

Hardly ideal. Another work around is to manually delete the file before activating the updated feature. Hardly voodoo or magic, eh?

One last tip – if you’re stuck with a feature that deploys a file and you want to update the file and implement a feature receiver to delete the previous version, you can do so by performing your deployment steps in the following order:

Retract Solution
Delete Solution
Add Solution
Deploy Solution
Deactivate Feature
Activate Feature

Your new feature receiver will kick in on the deactivate feature and delete the file for you. Just like magic…

MORE INFORMATION:

How to: Provision a File
SPFeatureReceiver Class

A Purpose

I've created this blog to share some of the lessons learned, trials and tribulations of working with SharePoint applications. After working with SharePoint for a while, I've become convinced that some portions of it work via some kine of voodoo magic, thus the name of the blog. I'm hoping that I can post some useful information here to help other figure out a way around some of the strange, murky inner workings of SharePoint and figure out where that last hidden configuration parameter is located that's going to make your clients or bosses happy that you were able to fix an issue that's been driving them crazy.