Sand boxed development in Visual studio 2010

After my initial search, i thought it's good to remember few things about sandbox solutions

The facts about Sand boxed development 

A new feature in SharePoint 2010, called sandboxed solutions, helps enabling farm administrators to feel comfortable that the SharePoint farm is safe, giving site collection administrators the authority to manage the applications in their site collection, and providing developers with the flexibility to create solutions they know will be deployed in a safe and rapid manner.

The structure of a sandboxed solution is very similar to a farm solution, which generally runs with full-trust permissions. The main differences lie in how a sandboxed solution is deployed and in the process that hosts the solution (which determines whether a solution is a sandboxed solution or a farm solution). This means that the same sandboxed solution can run with full trust when it’s deployed at the farm level and with partial trust when it’s deployed at the site collection level.

A SharePoint solution is a deployable package that can contain features and assemblies. The solution package is a .cab-based file with a .wsp extension. Visual Studio 2010 SharePoint project templates create .wsp package files. A solution might contain a number of SharePoint features, and these features provide functionality such as Web Parts, list definitions, modules, and event receivers.

When we open .package file in a sandboxed solution in Microsoft Visual Studio 2010 it shows that the global assembly cache is the deployment target of assemblies. But actually it is not stored in GAC or in file system.

 Actually, the sandbox process prevents accessing data outside the site collection where the solution has been deployed. This means, the following operations are not allowed in a sandbox framework 

• We can’t access the Internet to make Web service calls.
• We can’t access a hard drive to read or write files.
• We can’t access code that is not marked to allow partially trusted callers.
• We can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution.
• We can't do any security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed.
• We cannot deploy a visual web part using sandbox framework.

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. [Site Actions /Site Settings/ Galleries section/Solutions]. 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.

Debugging

We all know how to debug in full-trust solutions, which run under the IIS worker process used by SharePoint called w3wp.exe. Surprisingly, Sandboxed solutions do not run under this process. They run under the sandboxed worker process called SPUCWorkerProcess.exe, VS2010 automatically attaches the debugger to this process when we press F5. If a solution that’s already deployed we need to attach to this process manually.

MS Best practices says

• Avoid Creating Static Members 
• Avoid Throwing Unhandled Exceptions 
• Use Both the AllowPartiallyTrustedCallers Attribute and the SharePointPermission Attribute

What can be implemented in sandboxed solution?
Assembly
content types
event receivers
Feature
Feature receivers
Web parts
Field
Read more..

Things not allowed in sanboxed development

 - Read..