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