If you read any blogs about SharePoint, you will have undoubtedly read about using features and solutions to deploy your SharePoint customizations. While these work well in most cases there are some situation where you must take some precautions to ensure the deployment goes smoothly.

In my experience, the first deployment is not the real problem, it's the second. Many times I have had problems deploying features and it appears that my updates aren't applied. On my current project I have had this happen several times, enough to make me write this post about it. Hopefully this will help others avoid some of the hair pulling I have gone through.

So where are you going to run into problems deploying SharePoint customizations? Site Columns, Content Types, Layouts, and Web Parts are all parts of the solutions I have deployed in the past. And why do you run into problems? So far as I have seen, the biggest culprit in deployment problems come from files becoming 'Customized' or 'Ghosted'. When you deploy using SharePoint Solutions and Features you are doing so to the file system of the server, not to the content databases, and this is a good thing as it results in improved performance in most cases. When a file becomes 'Ghosted' or 'Customized' it means that SharePoint is no longer using the file from the file system, instead it's using a version that is being stored in the content database. What that means to you and your deployments is that SharePoint will no longer be grabbing the file from the file system where you just wrote the newest version.

So, by now you might be asking, how do these files get customized. Well, the most popular way to customize a file is to open it using SharePoint Designer (SPD). The blogs say that even if you don't write the file back, it's marked as customized and will continue to be so. This had lead to many denouncing SPD as 'Evil' and it should be avoided at all costs. I don't prescribe to that as there are many features of SPD that I simply couldn't do with out, like the Data View Web Part. I think that as long as you keep in mind the side effects of using SPD, and you only us it in your development environment you will be fine.

IF SPD is the most popular way to customize files, what other ways are there? I have found three ways that files will be, or appear to be, customized in SharePoint, none of which is as obvious as SPD. The SharePoint Web UI is capable of causing some things to be customized and some files get customized when they are deployed because of the way SharePoint determines their file types. Let explore each of the items from above and see what the issues are and how to resolve or avoid them.

Site Columns

When you deploy a Site Column into a SharePoint environment, you will be able to update that site column by simply changing the XML definition and upgrading the solution. It may take an IISReset to see the changes, but they will be there. However, if you make any changes to the Site Column using the SharePoint UI i.e the Web Interface, then the Site Column will become customized, and you won't be able to undo the change If the column is not in use then you can delete and redeploy, but I highly doubt this will be the case as Site Columns tend to be used quite often in Lists, Libraries and Content Types. If you think this may be your problem, use SharePoint Manager to inspect your Site Column and check the Version attribute.

If it's 0, it's not customized, if it's greater than 0, get used to using the UI to make changes to the Site Column, as I have not found a way to uncustomize it yet.

The next topic is more of a gotcha than anything else as it is actually a side effect of how SharePoint works. Site Columns in SharePoint act as templates, and when you associate a Site Column with a List or Library, SharePoint makes a copy of the Site Column and stores it with the List definition. This copy of the Site Column does not get updated unless you opt to update the Lists that use this column in the UI, or set the PushChangesToLists property of the SPField object to True, followed by a call to Update(). Be warned however, that doing either of these operations will cause your Site Column to be customized! {insert the famous Charlie Brown grown here}

To avoid customizing the Site Column, the only way I have found to get the List Fields to be updated is to actually, delete the column then add it back in again. If the column was in the list because of an associated Content Type then you can use the STSADM extensions from Gary Lapointe to propagate the Content Type into the list again.

Stay tuned for Part 2 - Content Types.