“No matter how impeccable your plan, you will encounter an error”
Unless you spend countless hours thinking through all the errors that you could run into, and perfectly designing a solution around that completely on your own, you are better off sticking to a plan and taking the errors as they come. What’s true about every error? Somewhere out there, a solution exists- you just have to find it!
When you start to develop a solution a question always comes up: Will this have a negative impact on the SharePoint environment? The best part is solutions are deployed in the solutions gallery, and run in the sandbox. I know what you’re thinking, and no, not the fun pit of sand you let your children play in, although there are striking similarities! The sandbox allows users to deploy their solutions- playing in the sand- and if something bad happens the environment- let’s say your backyard- is still the same as before! Once you are certain that your sandboxed solution will fix the problem, and not negatively affect the SharePoint environment, the administrator can run the solution.
Now the logical question is: How does SharePoint use this magical sandbox to do this? The answer lies in what the sandbox does. SharePoint protects itself from poorly written solutions by imposing these limitations:
- Resource Quotas: The solution cannot overuse resources such as memory, CPU queries, and database queries. If the solution does exceed a set criteria it scores a point- too many points, and the solution shuts down.
- No calls to web services- due to the internet’s general untrustworthiness.
- No access to data outside the local site collection
- No access to files on the hard disk
So the sandbox is a separate host process which ensures the user solution does not threaten the SharePoint environment.
I hope this blog has done two things: educated you on the sandbox for user solutions and prepared you to try a sandbox of your own!