SharePoint 2010 Sandbox Solutions

Sandbox solution: Deployed directly into a Site Collection (Solution Gallery).
Farm Solution: Deployed at Farm level at _layouts or GAC.

A site collection administrator, or another user with sufficient permissions, uploads the solution package to a specialized library—the solution gallery—in the root site of the site collection.
Sandboxed solutions are packaged as SharePoint solution package (WSP) files that contain assemblies, other non-compiled components, and an XML manifest file.

Uses and benefits of sandboxed solutions:

There are two common scenarios where it is appropriate to use sandboxed solutions:

• When an organization wants to run code for employees on a production SharePoint Server site, and that code has not been rigorously reviewed and tested.
• When a hoster wants to let the owners of hosted SharePoint Server sites upload and run custom code.

The main benefits of using sandboxed solutions are as follows:

• Sandboxed solutions can be added to a production SharePoint Server environment without the risk of affecting processes outside the sandbox.
• Site collection administrators can deploy sandboxed solutions. This frees farm administrators from this task.
• Scalability and flexibility are increased because sandboxes run in a separate process that can be restricted by quotas, and their effect on the farm can be monitored.
• A solution does not have to be modified or recompiled if it is moved from a sandbox to running directly on the farm.
• Technically speaking SharePoint solutions run in separate worker processes and not in w3wp.exe. So It doesn't require IIS Reset or Application Pool Recycling.

What Can I Do with Sandboxed Solutions?

Some common SharePoint development scenarios.This is not an exhaustive list; however, it serves to give you a feel for the types of scenarios that you can implement with a Sandbox solution.

Scenario	Sandbox	Hybrid	Full-Trust
Create a Web Part that aggregates data from multiple SharePoint lists within the same site collection. *
Create a Web Part that aggregates data from multiple SharePoint lists from different site collections within the same SharePoint farm.
Create a Web Part that aggregates data from multiple SharePoint lists from different site collections from different SharePoint farms.
Create a Web Part that displays data from an external list.
Create a Web Part that interacts with a Web service or a Windows Communication Foundation (WCF) service.
Create a workflow in SharePoint designer.
Create a sandbox workflow action (a method call).
Create a full-trust workflow activity.
Create a workflow in SharePoint designer that uses a full-trust custom coded workflow activity.
Create a fully coded workflow.
Deploy a new list definition.
Deploy a new list definition with list item event receivers.
Deploy a list definition with list event receivers.
Deploy a site definition.
Create a content type.
Create an external content type.**
Create a new ribbon element.
Create a new Site Actions menu item.
Create an instance of a SharePoint list.
Programmatically create a SharePoint subsite.
Bind a content type to the home page of a SharePoint subsite.
Deploy a new application page.
Create a timer job.
Create a service application.

*The Visual Web Part supplied with Visual Studio 2010 will not run in the sandbox. You must use the Visual Studio Power Tool in the sandbox.
**External content types are typically created by using the External Content Type Designer in SharePoint Designer 2010. However, they must be deployed using a farm solution or through the Central Administration Web site.

*Note: The standard Visual Web Part is not supported in the sandbox environment. The reason for this is because Visual Web Parts effectively host an ASCX user control within the Web Part control. The ASCX file is deployed to the _controltemplates virtual directory in the physical file system on each Web front-end server. The sandbox environment does not allow you to deploy physical files to the SharePoint root, so you cannot use a sandbox solution to deploy a Visual Web Part based on the Visual Studio 2010 Visual Web Part project template. 
HOWEVER:
A Visual Studio Power Tool is available that addresses this issue. A Power Tool is a plug in for Visual Studio. The tool will generate and compile code representing the user control (.ascx) as part of the assembly. This avoids the file deployment issue. You can download a Power Tool for Visual Studio 2010 that supports Visual Web Parts in the sandbox from Visual Studio 2010 SharePoint Power Tools on MSDN.
Hybrid: Hybrid approach means, combination of sandbox solution and full-trust solution (full trust: deployed at Farm level). The sandboxed component is deployed in a SharePoint solution package (WSP) to a site collection solutions gallery, and the full trust component is deployed in a WSP to the server farm. These components are typically developed in isolation, often at different times, and a single full-trust component can be consumed by multiple sandboxed applications.
Sandbox Limitations
As Sandbox is a secured wrapper and it has restrictions on code to run in SharePoint environment. Few Key limitations which developers should know are listed below.

1. No Security Elevation - RunWithElevatedPrivileges which runs the specified block of code in application pool account(typically System Account) context is not allowed in Sandbox code. SPSecurity class also not allowed to use in Sandbox.
2. No Email Support - SPUtility.SendMail method has been blocked explicitly in Sandbox, However .Net mail classes can be used to send mails. Additionaly sandbox won't allow to read Farm SMTP address. So developers has to specify the SMTP address in code itself(may be some other workaround).
3. No Support to WebPartPages Namespace - Sandbox won't allow to use Microsoft.SharePoint.WebPartPages namespace.
4. No Support to external Webservice - Internet web service calls are not allowed to ensure security in Sandbox solutions. Allow Partially Trusted code also can't be accessed within Sandbox.
5. No GAC Deployment - Sandbox solutions are not stored in File System(Physical path) and assemblies can't be deployed to Global Assembly Cache(GAC). But it's available on C:\ProgramData\Microsoft\SharePoint\UCCache at runtime. Note the ProgramData is a hidden folder.
6. No Visual Webparts - Visual Studio 2010 by default won't allow to create Visual Webparts to deploy as sandbox solution. But with Visual Studio PowerTools extensions(downloadable from Microsoft MSDN website) Visual Webparts can be developed and deployed as sandbox Solutions.

Microsoft (SharePoint) Office 365 supports only Sandbox solutions, it does not allow GAC deployments or file system access. 

Sandbox solution Model and other related articles:
http://msdn.microsoft.com/en-us/library/ff798382.aspx

Also see: SharePoint 2013 Preview: Sandbox Solution à Apps

--------------------------------------------------------------------------------------------------

About me: 
Vishnu Vadla, Dallas, TX.
SharePoint Consultant.
Specialized on Microsoft Technologies 
(SharePoint, ASP.NET, SQL Server Technologies)
--------------------------------------------------------------------------------------------------