currently I'm developing a SharePoint solution for a customer, which contains the following:

  • A custom field type
  • Two content types (one containing lookup fields to the list which is using the other content type)
  • Two lists templates, each based on one of the custom content type
  • Two list instances, based each on the provided list template

One of the content types is using a custom form via template approach.

Each of this is provided in a single feature which are all packed in on solution package.

As far as I can tell, one of the content types/list template/instance is far away from being final and my guess is that a lot of columns will be removed and added during the early stage of the project. What about rolling back an update?

As I have absolutely no access to the SharePoint installation the customer is using, I must provide every update to the content type and list template via a solution package.

After I have read a few resources about upgrading features, I'm living in fear that this project might have a catastrophic outcome, as testability and workflows for updating a feature are a huge mess.

Has anybody good resources for this process? What about new installations, when my feature already contains several updates? What about developing? As far as I know I will lose the ability to simply press F5 in Visual Studio, because VS will always retract the solution.

At the moment I'm totally confused how to handle this. Has anybody done something similar before?

1 Answer 1


We have exactly the same case as yours, our production and beta environments are not in our hand and we have to do deployments using WSP solution package (even if those are updates to existing solutions)

We also use content types, site columns and list definitions and instances, all declarative..

For the updates (I'm not sure if this is the best method but it works great in our environment), we usually write a Code Upgrader feature and the updates like deletion of site columns and updates in columns etc. we do programmatically in this feature and push changes to lists (includes content types being used in lists/libraries).. With this, we also update the declarative XML content types, list definitions etc. to match our new update..

The problem with content types declarative deployment is that the changes are not pushed to the lists/libraries using the content type and you need to programmatically push those changes (calling Update method with true attribute)..

Each time a new update is to be made, we usually comment out or completely delete (since using Version Control) the Code Upgrader feature code and write the new updates..

  • Just to be clear. You add a new feature, containing the code to update your existing content type and give it to the customer to deploy it on his environment. The same time you are updating the declarative xml in your existing feature, but this is not handed to the customer, right? Dec 19, 2014 at 22:05
  • 2
    That is handed over too, why won't you give those? Even sometimes we ReActivate those features in Code Upgrader feature (Let's say if a new list definition and instance is added). The best way to try it out in dev environment is not to use VS F5 or right-click deploy.. instead Publish the WSP in some folder, and use Retract, Uninstall, Add and Install-SPSolution cmd's from Powershell. Then run the code upgrader feature and debug as needed. Dec 19, 2014 at 22:11
  • We also use a somewhat similar approach as mentioned by @arsalan Dec 20, 2014 at 5:26
  • @NadeemYousuf if there are any differences, I would also like to a better/alternative approach :) Dec 20, 2014 at 12:31
  • @arsalan, there are not any significant differences. Dec 20, 2014 at 16:08

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.