[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 the right 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.
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.
- 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)
- 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 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!
- No ADO.net support, going back to BCS connect to a list that uses it instead of doing it in your webpart
- 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 GAC deployment, no loss here, just make a custom deployment method for complex deployments
- 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, in fact 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
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.