About Me

Having 12 years experience in Microsoft technologies.Since more than 7 years working in SharePoint technologies. Expert in providing consultation for SharePoint projects. Hands on with development and administration.

Wednesday, 10 October 2012

IN and OUT of SharePoint 2010 Sandbox solutions

Following are the major limitations for Sandbox solutions.

  • Scoped access to the SharePoint object model: Can able to access objects at the site collection level and below (SPSite, SPWeb, etc..). Cannot access to SPFarm & SPWebApplication              
  • Limited access to external (non-SharePoint) resources such as the file system based on Code Access Security (CAS) policies.
  • No code-based workflows, which use Workflow Foundation in .NET 3.5.
Sandbox solution execution process:              
    When a request is executed in the SharePoint server, it is passed to the User Code Service SPUCHostService.exe). In a farm solution, this calls the SharePoint DLL (Microsoft.SharePoint.dll) directly. In a sandboxed solution, however, this is passed to the Sandbox Worker Process(SPUCWorkerProcess.exe). This provides two important functions. First, requests for any non-SharePoint resources such as the file system are filtered through the CAS policy. The request is rejected if the needed access is not allowed. Secondly, it verifies that the SharePoint objects being used are within the scopeallowed for sandboxed solutions. Calls that manipulate the SPFarm object, for example, will be blocked.

Critical and important/technical question: Location of the sandbox solutions and Where are Assemblies in Sandboxed Solutions Deployed to?

The generic answer is - Since we are uploding solutions @ solutions gallery, it's abvious that the storage location for the sandbapx soloution is SharePoint content DB. It;s very easy to answer isn't it.?

YES, the entry is available in content database, however the DLL will not be stored in DB. That's the trick here... then where is the dll? good question. here is the answer:

 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 location is C:\ProgramData\Microsoft\SharePoint\UCCache. 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.

No comments:

Post a Comment