Limited 'Sandbox' that an application can be created in, it's limited to what it can do. Sandboxed applications upload at the site collection level in the Solution Gallery for the site. This means that the site collection administrator can control what applications can run in their site collection. If there is any problem with the application in terms of it's resources, it's disabled to prevent it from bringing down the rest of the site or the farm. In Central Administration you can block an application, set quota templates and resource monitoring. This overrides what the site collection administrator wants to do. To be able to use Sandboxed solutions you must set the Microsoft SharePoint Foundation User Code Service in Central Administration to be running. It can be running on all front ends, or specific web servers in the farm. The applications will reside in the Solutions gallery in the Site Settings. You can upload a WSP directly to the solution gallery, then you can activate or deactivate it at the site level. All the files reside in the 14 hive under the 'UserCode' folder. There is a web.config file as well, but it's a very simple one. It has a trust_level of 'WSS_Sandbox' which is in \config\wss_usercode.config. It defines the CAS policies that apply to the Sandboxed applications. You create the application like you normally do, you just set the trust level and choose 'Deploy as a Sandboxed solution'. This is the default setting for all Visual Studio projects when you create a SharePoint project template. They are recommending to use Sandboxed applications unless you have a need to access other resources that are restricted by the CAS. There is really no difference to Visual Studio as far as the project is concerned. It will change a metadata tag '[assembly: AllowPartiallyTrustedCallers()]' that will be added for a Sandboxed application. Nice, his demo shows how to add a custom action to the site menu. That can be a useful snippet of code. The Sandboxed application will not look any different when deployed, except that the application will reside in a different place, either in the site solution gallery, or in the Central Administration solution gallery. The execution manager in the application pool on the front end web server passes a request to the Host Services on the server, and kicks off a worker service to allow it to run. If a worker process runs for 30 seconds then the thread is killed. The application is then disabled until it is re-activated (and of course fixed with a new version that doesn't hang). Important note, the CAS policy is applied to your code in the worker process, but not to the SharePoint object model. So SharePoint can perform it's normal actions, while the application code is restricted. You can also update what's called an API block list to prevent code from making specific calls in case they are being exploited by a virus or worm. You can use a full trust proxy that can be called from a Sandboxed solution by putting it in the GAC. The difference is you can only expose the methods that you have control of so the Sandboxed application cannot exploit the SharePoint object model. This gives you a great point of control over what an application is doing, this provides visibility for what a piece of code has access too. Create a class that inherits from SPProxyOperationsArgs – the Arguments that are passed from the Sandboxed solution to the proxy. Then you create another class that inherits SPProxyOperation that will actually make the calls to the object model. The Sandboxed code will then create an instance of the 'SPProxyOperationsArgs' class, then passes it to the 'SPProxyOperation' using the SPUtility.ExecuteRegisteredProxyOperation method. I like this concept, it isolates all the potentially harmful calls into the proxy class, so a developer cannot simply 'slip in' a piece of code that does something that you don't want to happen. This would especially be useful if you have a contractor writing code, without having to go through all the code and look for potentially harmful calls. The proxies must be registered with the farm, this allows any Sandboxed application to call the proxy. There is no additional security around calling the proxy. You should create a common set of trusted proxies that all developers will be allowed to access. I like this as well, as your preventing 'Copy and Paste' code development, all the calls are done within the proxy. There are four areas of Sandboxed application administration. Load Balancing: You can put the UserCode service on all the web front ends, and then just let it spin up on the web front end that's making the request. Solution Validation: This validates a solution when it's loaded or activated, so it won't cause a problem until the code is used. This will make sure that a 'bad' application doesn't even get loaded on the site. Solution Monitoring: Monitor Sandboxed solutions, there are 14 measurements that can be monitored. They are given a value of 'Resource Points', and then set the maximum number of resource points that an application can use. Once an application exceeds this it is deactivated. This is set by the Farm Administrator, and then he monitors the results based on the rules he's set. You can also set a warning level that will send an e-mail when an application reaches a certain number of resource points. There are ways to configure this using PowerShell and the SharePoint snap-in for PowerShell. Solution Validators are created by inherting from SPSolutionValidator. It allows you to walk through a solution and examine its components to determine its characteristics and if you consider it harmful. Validators have a signature ID, similar to a template ID. Validator is called once for the package, and once for each assembly in the package. Then you receive the SPSolutionValidationProperites has properties that can be examined for the items you want to check. There are two overridden methods one for the package, and one for the assembly validation. To register the validator you make a feature receiver to deploy and register it in the farm.
You can also set up a dedicated server to handle all the Sandboxed application requests.