At first, I'm wondering if this would be a good idea, at all...

However, I have a project (http://sharepointadlds.codeplex.com) that creates two Content Types as well as two Lists in Central Administration. On Solution retraction, obviously the Content Types are removed, but the Lists are not. This leads to being unable to manage the Lists, which is not good.

I'm wondering if it is possible, on Solution retraction, to leave the Content Type behind, or should I just outright delete the Lists instead?

1 Answer 1


Actually, you can do both - just decide if the list is beneficial to the user even without your solution.

The easiest way is to delete the list in the feature receiver. I assume it was created automatically during your profile synchronization and contains no data created by the user. If the user wants to retract your solution they are not going to need the list anymore, aren't they? They could also back up the list to CSV/Excel for read-only purposes.

If you find worth to retain the list as-is after the retraction, you could divide your solution to two - one with the UI support (fields, CTs, ...) and one with the functionality. The user could retract the latter; the first they would keep as long as they want to keep the content.

Well, the idea of two solutions seems too complicated. Another possibility to retain your CT would be not tying it to a feature manifest. When you deploy a CT on a feature activation SP will remember it; you should not hack the SP configuration to untie the bond so that the CT remains. If you create you CT programmatically it will survive the retraction just as any other object deployed as content. (See also another howto.)

--- Ferda

  • Thanks, I believe deleting the Lists might be more appropriate (and easier on me, at any rate). The information contained in the Lists should be known by the Administrator.
    – user6024
    Apr 30, 2012 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.