SharePoint 2010 Sandbox Solution

Sandbox solutions allow you to: 1.       Deploy custom code you have developed or downloaded from the Internet 2.       Such custom code you deploy cannot jeopardize the stability of your farm 3.       Solutions are being deployed via web interface 4.       If you are running SharePoint in a hosted environment you will be deploy SandBoxed solutions there as well 5.       **Important- VS 2010 can open the .WSP file 6.       To upgrade Sandbox solution - Open the Existing solution(.WSP) in VS 2010 and do the modification and upload into the Site    collection Solution gallery 7.       **Important- Cant upload the Farm solution to the Sandbox solution, It will give Partical truster caller error Sandbox Solutions support the following SharePoint item types: 1.       List definitions 2.       List instances 3.       Content Types/Fields 4.       Navigation 5.       Web Parts derived from WebPart 6.       Event receivers 7.       Custom Workflow Actions 8.       Workflows Where are Assemblies in Sandboxed Solutions Deployed? The assemblies in a sandboxed solution are included in the solution package (.wsp file), and the package is deployed to the site collection's Solutions Gallery. When a sandboxed solution is accessed for the first time, such       as when a user navigates to a page that contains a Web Part from a sandboxed solution, any assemblies in the          solution are extracted from the package in the gallery and copied to the file system of the server that is handling the sandboxed request. The default location is C:\ProgramData\Microsoft\SharePoint\UCCache; however, this is configurable on each server that is running the User Code Host Service, which is called the Microsoft SharePoint Foundation Sandboxed Code Service in the user interface of the Central Administration application. The executable of this service is SPUCHostService.exe. The server that handles the sandboxed request is not necessarily the front-end web server that is handling the initial HTTP request: The Microsoft SharePoint Foundation Sandboxed Code Service can be run on back-end application servers in the farm instead. Because the sandboxed user process (SPUCWorkerProcess.exe) cannot copy anything to the file system, the copying is done by the Microsoft SharePoint Foundation Sandboxed Code Service. The assemblies of a sandboxed solution do not stay in the file cache perpetually. When the user session that accessed the solution ends, the assemblies stay in the cache for only a short time, and they may be reloaded from there if another user session accesses them. Eventually, if they are not accessed, they are removed in accordance with a proprietary algorithm that takes into account how busy the server is and how much time has gone by since the assemblies were last accessed. If the sandboxed solution is used after that time, the assemblies are extracted again and copied to the UCCache. Reference: Best Practices: http://msdn.microsoft.com/en-us/library/gg615455.aspx http://msdn.microsoft.com/en-us/library/gg615461.aspx 10 reasons to use Sandboxed Solutions 1.       It doesn't require IIS Reset or Application Pool Recycling. 2.       Central Administration (CA) gives a way to block the sandbox solutions. In CA under System Settings you can see the “Manage User Solutions” option 3.       Sandboxed solutions are secure. 4.       Sandboxed solutions can be monitored. 5.       Sandboxed solutions do not affect other sandboxed solutions, well atleast not in other site collections is what I mean. 6.       Sandboxed solutions do not touch the file system for the most part 7.       Sandboxed solutions skip application pool recycles, so debugging is not such a pain. 8.       Sandboxed solutions allow the site collection administrator to perform deployment and upgrades 9.       Sandboxed solutions make CAS policies look like the out of style hairstyles of 1980s 10.    The Solution validation framework for sandboxed solutions is exntensible, simply inherit from the SPSolutionValidator base class. 11.    Sandboxed solutions remove the need for line by line code reviews 12.    Sandboxed solutions allow you to offer different level of SLAs to different site collections using Resource Quotas. Limitation: 1.       The sandbox process prevents you from accessing data outside the site collection where the solution has been deployed. This means, for example, that you can’t access the Internet to make Web service calls, 2.       You can’t access a hard drive to read or write files, 3.       You can’t access code that is not marked to allow partially trusted callers. 4.       You also can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution 5.       Security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed.

 References- http://forums.sikigroups.com/