I have developed a portal and we have integrated with Oracle E-Business Suite. In this project we have complex form requirements so I developed custom aspx forms mainly master-detail forms and lots of complex code behind code due to its nature which seemed not possible in OOTB as we have standard edition and don't have INFOPATH.

we have developed visual webparts (custom aspx forms) and deployed as farm solution. Now I need to learn Sandbox thingy. Keeping my requirement in mind should I go for Sandbox from now on and ive heard in sandbox you cannot use code behind. So based on my requirement of code behind what should I do.

2 Answers 2


If it is just for learning don't go for it, there should be a sound reason behind this decision...

Most helpful can be to have a look at Limitations of Sandboxed Solutions in SharePoint 2010, most importantly look at the project types it doesn't support! Also look at Understanding the SharePoint 2010 Sandbox limitations

If you really want to start with Sandbox solution, do it... At any point in time you think Sandbox is limiting you, you can make it a Farm Solution and deploy! But as I said, there should be a sound reason like a security threat or farm protection etc!

SharePoint 2010 Sandbox Solutions are Bad, this might help in making a decision!

I hope this helps


[Examples near the bottom]

Okay, Sandbox solutions aren't going to go away any time soon (No matter how much I wish they would) BUT there is good news, with new development methods Sandbox solutions can have almost as much functionality as a full Farm solution.

Code behind files can be replaced by a webpart, and where needed with the CSOM (SPServices finishes this off from CodePlex)

Custom JS and CSS, Master pages and layouts get deployed as modules, which are activated in the feature. They are all set as ghostable and their URL property mapped to where you want it.

For elevation, you have to use a app hosted externally, which authenticates your user then runs the elevated task.

etc etc...

Sandbox Solution are used by most large organisations as the ONLY deployment type allowed, if you don't become used to writing them, you will cost a lot of extra development time.

Farm solutions are "dirty" but a required evil, Sandbox are difficult but a required evil. Basically both are evil in their own way.

Write a Farm solution wrong and you will risk breaking your box, breaking security or something else just as risky if you are just starting out.

Sandbox solutions are limited, but organisations use them as protection against bad code, or bugs in code, they can't break the server and they can't cause the server to slow down.

On top of this, anything that has processing involved should run under a monitored scope. This will mean if anything you write does go wrong, the cause can be pinned down and your code disabled awaiting a fix.

Sandbox solutions are depreciated in 2013, but I know for a fact that since they are still there, certain large organisations are sticking by Sandbox solutions and will not back down.

There isn't a limitation of a Sandbox solution that cannot be overcome, this is the fact of the situation, and they heavily help create a more stable server.

Examples of what you think cannot be done and how to get around them:

  • Logging, you cannot use the ULS to custom log events, you can however use monitored scopes to output verbosely to the ULS everything within, and you can create a hidden list and log what you would manually log to it.

  • Taxonomy, with the taxonomy namespace restricted you have to turn to a client side solution with SPServices to do everything you are blocked for

  • Elevated permissions, to achieve this you need to have an externally hosted app which can authenticate your user with SharePoint and run the required process using WEB Services / RPC for you

  • Custom Master page (Similar for js, css, layouts etc) you add the file into a module in your solution, and in the elements file set the URL to the location you wish it to appear and then set it as Ghostable or GhostableInLibrary depending on what you want to do

  • You can't get external site collections, again go to JavsScript for this and use the CSOM

  • Visual WebParts aren't supported, but you can use CKS Dev/Power tools to give you this functionality back.

  • You cannot call external databases, again you can dive into the JavaScript, or use a BCS connected list to surface the information for you

  • Only designer workflows allowed, not a big deal, you can either use a product like K2 Workflows or just create it with event receivers (Which are usually faster anyway in my book)

  • You can't use system IO, again just go through JavaScript here and use the author.dll RPC the same as Office/Designer do

  • Hide custom action/custom action group are not allowed, this isn't a problem if your custom actions are made correctly, but you can still use security trimming and use JavaScript/css after disabling with security trimming!!

  • No feature stapling support, this is a hard one to overcome, but using events like SiteProvisioned etc can overcome this

  • Can't write to the registry but you can read, WHY WOULD YOU WANT TO!!!

  • Can't set cookies in sandbox, but you can use JavaScript to do this again!

  • No call to external Services, but again JavaScript (See where I am going CSOM is your friend)

  • Can't use sharepoint mapped folders such as layouts, RUBBISH as I said just ghost the file from a module into the folder, even works on public facing 365

  • Can't export a sandboxed webpart, technically this is the hard one, but really good standards and practices you should have this in code anyway!

  • Microsoft WebPart controls and Pages aren't available. There are SharePoint controls for almost all ASP.net and if not CKS dev also helps. Further you can create JavaScript modifications

  • No ADO.net support, going back to BCS connect to a list that uses it instead of doing it in your webpart

  • No support for sendemail, so write a proxy service to send emails! Or use an external app and JavaScript

  • No Cacheing support, you can create custom cacheing for complex HTML using a HTML field in a custom hidden list to prevent re generation

  • No site definition, this can be done using modules instead

  • No localisation support, you would be using international, but if it is a hosted SharePoint you would set this up regardless

  • Microsoft.Sharepoint.Administration is disabled, use SPServices to get around this

  • No document converters, this is just training, they would save as the trained file, converting externally sent files on save to SharePoint in Office

  • No access to scriptmanager, this doesn't stop you from doing anything at worst you can use a webpart or javascript

  • No GAC deployment, no loss here, just make a custom deployment method for complex deployments

  • No redirects server side, use JavaScript redirects or nice Modal boxes to display data/messages

  • Can't directly access some enterprise services, like UPM or Search, but you can just use one of the other models to access this information

  • Can't access DLLs from BIN and resource files. This doesn't hit you with any issues, infact I see doing this as an almost bad practice, this could be abused by a hacker anyway. You can do anything you need in other ways

  • Can't access code that is marked as partially trusted callers, this is again fine, if it is to hard to do then just make a COSM version of what you need to do or make a trusted version

  • Only SPLimitedWebPartManager is available, there is nothing you should need to do that you need to do. Anything to heavy can be moved to a CSOM ran page through JavaScript

I am going to write this up and extend it for every blocked namespace for sandbox solutions. Random guides for each work around are about but I will aim to put in one place.

So once more with feeling, large organisations will love you if you can develop freely, securely and quickly in a Sandbox solution.

  • 1
    +1, very informative... However, even though you CAN overcome most obstacles in a sandboxed solution, it tends to take (much) longer to develop and test compared to farm solutions, and because these processes tend to be a mix-and-match of various technologies, it also becomes harder to maintain. It also doesn't help that not everything is documented perfectly well and that some things simply behave differently in sandboxed or farm solutions. Short version: if you can do it sandboxed, great, but insisting on doing so can cause more headaches than it's worth. Commented Dec 10, 2012 at 7:44
  • 1
    Unfortunately when you get to bigger and bigger business, sandbox becomes a much required evil by company standards. Also putting more and more clients on 365. While we wish this wasn't the case it is, but the CSOM + SPServices 99% overcomes this for us.
    – Hugh Wood
    Commented Dec 10, 2012 at 9:20

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.