1

I had created a project that defined some content types and lists via XML. After it's release we need to make some updates to this feature to include some new functionality. My concern is that since this was all done via XML major issues could occur.

The lists initially created are critical. By doing an upgrade-spsolution is it going to tear down the lists and try to provision new ones or will it see they already exist and do nothing? The updates aren't touching the lists themselves, but updating some ASPX pages, javascript files, and adding in localization.

Since this project, I've moved to creating and provisioning lists via feature activation code instead of static list instances, I could handle it all in the feature upgrading event receiver if that were the case.

Improve this question
1
  • Following the methods outlined here msdn.microsoft.com/en-us/library/office/… and you should be fine (e.g Feature Upgrading event in receiver and the part about adding modules). The important part is to not disable / enable the feature, but upgrading it with powershell or third-party tool
    – Robert Lindgren
    Commented May 16, 2014 at 17:33

1 Answer 1

Reset to default
1

Lists defined via XML get wiped out if you choose "Deploy" from Visual Studio, but remain intact using Update-SPSolution. If you are only changing deployed files, pages, or code in your assembly, your changes should get pushed through with an Update-SPSolution.

The only thing you may need to consider is that files that were deployed to SharePoint via Modules in SP 2010 aren't automatically overwritten using Update-SPSolution so you will have to remove them first if there are modifications to them. This is not the case with files deployed to the file system. Important to note is that the Update-SPSolution command does not trigger the SPFeatureReceiver.FeatureUpgrading event so that is not a valid approach to removing these files. See: Does Update-SPSolution trigger a SPFeature.Upgrade()?

In SP 2013 you can use the ReplaceContent="TRUE" attribute to handle this problem. See: Overwriting ghostable files in SharePoint 2013 libraries using feature elements (no code)

Improve this answer
2
  • Good to know the lists will remain in tact. The various aspx pages were created via modules, so prior to upgrading I'll need to go ahead and delete them then. My only concern with that is if people have liked/tagged it via the social features, is that going to get wiped out.
    – Eric Alexander
    Commented May 16, 2014 at 20:22
  • I don't know for certain, but my guess would be, yes, those values would get wiped. I like using the XML approach for custom lists, so I deal with this on a regular basis. One thing I tend to do with my solutions is to use one wsp to provision my data backend (lists, libraries, etc.) and a separate wsp to deploy my code so that full uninstall/reinstall processes for code don't affect any of the "more permanent" assets.
    – RJ Cuthbertson
    Commented May 16, 2014 at 20:37

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.