Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a sandboxed solution with these items:

  • A module
    • Elements.xml (ElementManifest)
    • HelloWorld.txt
  • Package
    • MyPackage-1.0.1
  • A feature
    • Scoped for site

In addition the solution is set to Include Assembly = False.

I want this solution to be 'upgradable'.
When end user upload a new version of my WSP they should be able to click 'Upgrade' and the files are renewed, and the Elements.xml updated.
If I change package name (For example from MyPackage-1.0.1 to MyPackage-1.0.2) the solution is upgradable, but files are not changed.


So far I have come by two different ways to do this, the first is a hack and the other is a hack.

Hack 1

Use Client Object Model to delete the files. I do not have a good example of how to trigger the script (could be done from listening to the "Upgrade" button), but deleting the files is quite easy:

var ctx = new SP.ClientContext();

Hack 2

It does seem that Elements.xml is updated, so it is possible to inline the whole script into this file. This could be added to Elements.xml with a build script or similar, as one would probably not want to write JavaScript or CSS directly in Elements.xml.

share|improve this question
What files are not changed? HelloWorld.txt is not updated? –  James Love Sep 12 '12 at 12:23
As well as my Elements-file, (CustomAction). I have thought about GhostableInLibrary/Ghostable, but it didn't seem to make a difference, but perhaps it will only work first time when done correctly. I removed the files with PS. Also by my understanding Ghostable/GhostableInLibrary would be kind of strange on a sandboxed solution where file system is restricted anyway, but... –  eirikb Sep 12 '12 at 12:59
After you upgrade the solution in the gallery, are you going to Site Collection Features and deactivating then activating? –  andrew.petersen15 Nov 14 '12 at 16:37
No, I click Upgrade. But I have tried that also, as well as remove/add. –  eirikb Nov 14 '12 at 16:40
add comment

2 Answers

A site collection administrator upgrades a sandboxed solution by installing a new sandboxed solution package (.wsp file) that has the same solution ID as the existing sandboxed solution but a different hash code.

If the sandboxed solution contains any Features, feature upgrade actions are also processed: During upgrade, the Feature definitions for the existing solution are compared with the Feature definitions for the new solution. Existing Feature definitions are upgraded on the site. All new Feature definitions are activated on the site. (Incoming requests for the sandboxed solution fail during the upgrade process.)

Installing, Uninstalling, and Upgrading Sandboxed Solutions in SharePoint 2010

share|improve this answer
I guess you mean that the my feature will be upgraded (and then my module referenced in that) if I change the feature definition? Well I tried setting a feature version Open feature -> Version ->, but my Elements.xml did not seem to be updated (CustomAction). Also I'm relying on solution gallery in Site Settings so anyone with SPSite (Site collection) permissions should be able to upgrade. The "Upgrade" button works when I change Package name, just nothing happens –  eirikb Sep 12 '12 at 12:58
I'm having this same problem, so if you've solved it, please let me know. –  Renan Jul 22 '13 at 18:29
add comment

Module files are indeed a problem to update or overwrite. If I understand you correctly, this is the problem you are facing? That, after deploying a newer .wsp, the old files are still present and not overwritten?

The basic issue is that module files remain when the feature containing the module is disabled or uninstalled. To resolve this, I got into the habit of manually cleaning up:

// When we deactivate the feature, we need to delete the module
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
    using (SPSite spSite = properties.Feature.Parent as SPSite)
        using (SPWeb web = spSite.RootWeb)
                SPFile file = web.GetFile("MyModule");
            catch { } //sue me

This is made easier by the fact that, by default, all your module files will be gathered in one folder. So you just need to delete the folder. This solves the problem whenever you can deactive the existing module before deploying the new one, and frankly is a good habit in itself in my opinion.

Upgrading is more annoying. You are deploying a .wsp that wants to deploy files that are already present on the system. I recall trying that and I remember having to use the IgnoreIfAlreadyExists argument to make it overwrite existing files, which goes something like this in your elements.xml:

<File Path="MyModule\myfile.txt" Url="MyModule/file.txt" IgnoreIfAlreadyExists="FALSE" />    
share|improve this answer
Thanks for the answer, but the whole point about the question is to not have a DLL, hence your example code can not exist. And the scenario is basically for upgrade, not deactivate/activate. I must admit I have not tried IgnoreIfAlreadyExists, but I did not think it would help in my case. –  eirikb Nov 14 '12 at 16:39
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.