Where are Assemblies in Sandboxed Solutions Deployed?

Because sandboxed solutions cannot deploy files to a server's file system, there is some puzzlement over where the assemblies in sandboxed solutions are deployed and persisted.  The situation is not helped by the fact that the package manifest of a sandboxed solution implies that such assemblies are deployed to the GAC as the following screenshot shows. This is not the case.

The assemblies in a sandboxed solution are included in the solution's 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 containing a Web Part from a sandboxed solution, any assemblies in the solution are unpacked from the wsp and copied to the file system of the server that is handling the sandbox request. The location is C:\ProgramData\Microsoft\SharePoint\UCCache. The server that handles the sandbox request is not necessarily the front-end web server that is handling the initial HTTP request: the User Code Host Service can be run on back end application servers in the farm instead. Since the sandboxed user process (SPUCWorkerProcess.exe) cannot copy anything to the file system, the copying is done by the User Code Host Service.

The assemblies do not stay in the file cache perpetually. When the user session that accessed the assemblies ends, the assemblies stay in the cache for only a short time and they may be reloaded from there if another user session assesses 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 unpacked again and copied to the UCCache.

Administrators, developers, and third-party code should not add, remove, or load anything from the UCCache. It should only be accessed by the SharePoint infrastructure.

Rick - MSFT

Comments (7)

  1. Nik Patel says:

    Nice job.. there was lots of myth around this.

  2. Sridhar Bommana says:

    Thanks a lot… that is very informative.

  3. Sandboxed code execution request failed withTelerik Controls says:

    I am developing a sandbox solution which will display an SPList in telerik grid. But i got some Request error. "Sandboxed code execution request failed" . I have posted in telerik, they saying it is microsoft problem.

    I need to use telerik controls in office 365. Is there any way for that?

  4. @Telerik controls:

    The error you are getting usually means that your sandboxed solution violates one of the restrictions on sandboxed solutions.

    The best I can do is point you to the SDK topic:

    Restrictions on Sandboxed Solutions in SharePoint 2010 (msdn.microsoft.com/…/gg615454.aspx)

    This is the most detailed and authorative source about what you can and cannot do in a sandboxed solution.

    For example, if the Telerik DLL does not have the attribute Allow Partially Trusted Callers, then it cannot be used in a sandboxed solution. Or if it calls into a .NET assembly that is not allowed in sandboxed solutions or if it calls a forbidden API in the Microsoft.SharePoint.dll, then it will not work.

    But the problem may not be the Telerik control at all. Maybe there is something else in your solution that violates one of the restrictions.

  5. vamsi says:

    very good explanation.

  6. venkat says:

    Good  article and very informative.

  7. Kalpesh_Vaghela says:

    Nice Information..

Skip to main content