After having done some work with a sandboxed solution I encountered an unexpected limitation. It was an old Sharepoint 2007 solution that I was trying to upgrade to Sharepoint 2010, and in the process I attempted to keep it as a sandboxed solution well knowing that there would be some limitations.

The upgrade was going fine and I was fixing errors due to the subset of the available Sharepoint API, but all the errors were more or less expected. The webpart was deployed correctly and seemed to be working fine. Admitted, it wasn’t necessarily what you would call a standard basic webpart, but again it wasn’t overly complex.

What it did have though was a webpart property that should be persisted, which type of a specifically implemented type for which I had created a special editor part used for setting the property. In SP2007 everything worked fine. My editor part provided a specific user interface and I set the custom property which Sharepoint then persisted for me, so I could read it at a later time.

When I tried this logic in my sandboxed solution I was met with the following error

  Web Part Error: Unhandled exception was thrown by the sandboxed code wrapper's Execute method in the partial trust app domain: Web part property 'Number' uses unsupported type (System.UInt16), and cannot be run as a sandboxed code web part.

I started scratching my head wondering what that might mean. Everything else on the webpart worked properly, so this error only occurred when I tried to save updates to my webpart configuration.

After a while I attempted to launch my webpart as a  farm solution instead to see if that was still working of it was some Sharepoint 2010 tweak, that made my webpart failed. And when launched as a farm feature everything worked.

So, what to do then. Well I like to debug, so I quickly opened reflector and started looking around trying to locate the root of my exception, so I should find the top of the stack, which was

WebPartPageUserException: Web part property 'Number' uses unsupported type (System.UInt16), and cannot be run as a sandboxed code web part.]
  at Microsoft.SharePoint.WebPartPages.SPPTCPropertyEntry.ConvertToPersisted(Object propValue)
  at Microsoft.SharePoint.WebPartPages.SPPTCPropertyEntry.GetValue(Object control)
  at Microsoft.SharePoint.WebPartPages.BinaryWebPartSerializer.Serialize(PersonalizationScope scope)
  at Microsoft.SharePoint.WebPartPages.BinaryWebPartSerializer.get_SharedData()

So I ended up locating the file C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\UserCode\assemblies\Microsoft.SharePoint.dll which contained the method causing the exception. Looking at that I spotted a very peculiar behavior. What I found there is a handler to serialize the data that the should be saved as a webpart property. Looking at the code I could see that this serialization method tested the property type and threw the above exception if the type did not match any of the defined types. It turns out that only the following types are supported

• string
• bool
• Enum
• short
• int
• Guid
• Uri
• byte
• char
• long
• float
• decimal
• double

So if you want to have a custom webpart property with a type that is not listed above, then a sandboxed solution is not the way to go. I at least cannot see a workaround to this limitation.

I then made a very simple webpart just as a proof of concept. It has the following 20 lines of code

using System;
using System.ComponentModel;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;
namespace SPWebpartTest.GenericWebpart
{
    [ToolboxItemAttribute(false)]
    public class GenericWebpart : WebPart
    {
        [WebBrowsable(true), Personalizable(PersonalizationScope.Shared)]
        public UInt16 Number
        {
            get;
            set;
        }
        protected override void Render(HtmlTextWriter writer)
        {
            writer.Write("The number is: " + Number);
            base.Render(writer);
        }
    }
}

This webpart can only be deployed as a farm solution if you wish to modify the Number property using the regular webpart framework for Sharepoint.

So beware out there if you plan for Sandbox deployment this is yet another limitation.