Aracılığıyla paylaş

Where are Assemblies in Sandboxed Solutions Deployed?

  • Makale

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

  • Anonymous
    October 09, 2010
    Nice job.. there was lots of myth around this.

  • Anonymous
    October 15, 2010
    Thanks a lot... that is very informative.

  • Anonymous
    October 12, 2011
    The comment has been removed

  • Anonymous
    October 13, 2011
    @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.

  • Anonymous
    May 27, 2013
    very good explanation.

  • Anonymous
    September 23, 2014
    Good  article and very informative.

  • Anonymous
    July 06, 2015
    Nice Information..