Although I originally thought the answer was Yes to my question, upon further review, the answer is NO, you cannot create a custom web part targeting the Sandbox and activate the solution without a Site Collection Administrator. I was premature in posting that you can do this without fully testing using proper permissions. I was excited that I was able to configure a VS2010 project to scope a Web Part to "Web", rather than "Site" scope, that I hand't properly tested. Apologies for confusion. I've left my steps for creating a "Web" scoped Web Part feature below, but they won't do you much good for reasons about to be explained.
The reason this is not a feasible option comes down to some logic sitting behind the ActivateSolutionItemButton which appears in the toolbar for the page used to activate the solution (_catalogs/solutions/forms/activate.aspx). The logic resides in an SPUserSolution.CurrentUserCanActivateSolution() (internal static method). It checks to see if the solution contains assemblies (aka code), and if so, it checks that the user is a Site Collection Admin (SPSite.RootWeb.CurrentUser.IsSiteAdmin). If the solution (.wsp) doesn't contain code (for example Content Type, List Instance, Modules, Custom Workflow from SPD, etc), it just checks for one of the following:
- SPBasePermissions.AddAndCustomizePages
- SPBasePermissions.ManageSubwebs
- SPBasePermissions.ManageWeb
For this reason, you are limited to "no code" solutions, unless you are (or have access to a willing) a site collection administrator.
**
NOTE: the rest is my original posting about how I created a "Web"
scoped web part feature...
**
Here is a summary of the steps needed to create a "Web" scoped Web Part feature and package it as a Solution targeting the Sandbox:
- Create a new Empty SharePoint project in VS2010. Setup as Sandboxed.
- Add an "Empty Element" (SPI). Ensure resulting Feature is Web scoped (should be by default).
- Add a project reference to System.Web.
- Add a new .cs (or .vb) class file. Set it up to inherit from System.Web.UI.WebControls.WebParts.WebPart and give it a proper name. Take note of class name and the namespace (change any as needed).
- In the web part class, override CreateChildControls() and do something simple, like output a Label control (you may need to add a "using" for System.Web.UI.WebControls).
- Add a text file under your "Empty Element" SPI (i.e. as a peer to the elements.xml). For simplicity, name it .webpart. (where is the class name given in step 4 above).
Open the .webpart file and enter the following:
Cannot load the web part!
webpart title
web part description
Open the elements.xml and enter the following making appropriate replacements:
Open the properties panel for your EmptyElement and add a Safe Control Entry ensuring the namespace matches the namespace of your web part (from the class file).
Package, Deploy, Test.
The downside to this is that you have a Web Scoped feature, so it would appear that you need to activate this on all subwebs, but because the Solution and Web Part Galleries are scoped to the Site Collection, we actually have no need to activate this on sub sites and the web part is still available on them. It does no harm to activate on any Sub Webs because the Module element is configured with RootWebOnly="TRUE".
Although it doesn't make sense to create a Web scoped feature for a Web Part at first glance, it may if your circumstance matches mine. That is, you have permissions to manage the Solution and Web Part Galleries, but don't have full Site Collection Administrator priveleges. This is possible because these galleries do not require Site Collection Administrator permissions. A "normal" Sandbox Feature containing a web part has "Site" scope and cannot be activated by someone who can manage these galleries, because feature activation at the Site Collection level requires Site Administrator permissions.
