Checking the Sandbox solutions settings using Powershell

Display the sandboxed solutions service configuration settings:


$uc=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local

foreach($tier in $uc.Tiers)
{
Write-Host "Tier Name: $($tier.Name)"
Write-Host "Tier MaximumWorkerProcess: $($tier.MaximumWorkerProcesses)"
Write-Host "Tier MaximumConnectionsPerProcess: $($tier.MaximumConnectionsPerProcess)"
Write-Host "Tier MaximumAppDomainsPerProcess: $($tier.MaximumAppDomainsPerProcess)"
Write-Host "Tier PriorityPerProcess: $($tier.PriorityPerProcess)"
Write-Host "Tier ResourceMaxValue: $($tier.ResourceMaxValue)"
}
 
Reference: http://technet.microsoft.com/en-us/library/hh230317.aspx

Sandbox solution ULS logging

Overview: Step-by-step instructions to create a logging module for Sandbox solutions using a full trus proxy that logs to the ULS.

Steps:
1.> Ensure Sandbox solutions service is running:

1.1.> If the "Microsoft SharePoint Foundation Sandboxed Code Service" is stopped start it either thru CA (shown above or PS). 

PS> Start-Service -Name SPUserCodeV4

1.2.> Ensure the Windows service is running.

2.> Create project to test the full trust ULS logging proxy.

2.1> Create a Visual Studio project that deploys as a sandbox solution (test rig)

2.2.> Create a visual web part for sandboxed solutions (VSIX/Extension maneger: Visual Studion 2010 SharePoint Power Tools)

Note:  The submit button does not perform any action as the Full Trust Proxy must be created and deployed so we can use it to log code to the ULS.

3.> Create a ful trust proxy that code in the sandbox solution can call to add the error message to the ULS logs.

3.1.> Create an empty SharePoint project using Visual Studio 2010that deploys to the farm.
3.2.> CKSDev (VSIX extension has a SPI template to create a full trust proxy).  I used the SPI to create my ful trust proxy.
3.3.> Create the code to log to the ULS

3.4.> Edit the full trust proxy to use the ULS logging code created above.

4.> Add the proxy code call to the test rig/proxy caller i.e. sandboxed solution code.

Tip: Resart the Sandbox solution work process after each deployment

Tip: Use Powershell to check a correlation Id quickly:
PS>Get-SPLogEvent | ?{$_.Correlation -eq ""} | ft Category, Message -Autosize

References:
http://msdn.microsoft.com/en-us/library/gg622617.aspx
http://www.zimmergren.net/tag/sps
http://www.wictorwilen.se/Post/Working-with-SharePoint-2010-Correlation-ID-in-PowerShell-and-code.aspx

Deploying Code on a SharePoint farm

Problem:  On large farms you may want to restrict code access to different levels, SharePoint 2010 offers 3 options as opposed to MOSS offering 2 options: GAC & Bin.

Initial Hypothesis:  Custom code can go into 3 places in SP2010:
1) GAC (easiest)
2) Bin
3) Sandbox 

GAC is the most open but you may want to restrict what code an do and where it can run.  In 2010 sandbox solutions or bin deployments are more restricted.  Sandbox solutions are way more restricted programatically then bin deployment but they are safer, also note that sandboxes can slow your farm down until the offending solution is expired for the day by SP2010.

Tip: Some code won't work in the bin such as workflows.  Seperate the code so if you are using the bin it goes into the bin and workflows and item events are added to the GAC, ensure you use dll versioning in the GAC (note: Workflows in progress will fail if you simply upgrade the dll in the GAC).

Tip: Include a referenced dll in your wsp deployment:

More Info:
http://msdn.microsoft.com/en-us/library/cc768621.aspx

WebControls not supported in sandbox solutions

Problem:  I wanted to use a SPGridView in a sandbox solution, so I added the code an intellesense doesn't pick it up.  Looked up the SPGridView class documentation on MSDN and it's not supported.  Not really sure why but hardly anything in the Microsoft.SharePoint.WebControls assembly works with sandbox solutions.

Initial Hypothesis:
Microsoft.SharePoint.WebPartPages.ListViewWebPart is another example of a control that can't be added progratically, however it can be added using SharePoint Designer.  I'm baffled!

Where are Assemblies in Sandboxed Solutions Deployed?

I found this article on where Sandbox Solutions store their assemblies.   As I didn't know this thought I would share the info.

Assemblies (dll's) are packaged into Sandbox Solutions and deployed into the Solution Gallery of the Site Collection.  Sandbox solutions cannot work with local resources.   When the sandboxed solution is accessed for the 1st time, the wsp (sandbox solution) is unpacked and the dll's are copied to the file system for each server that handles the request to a file location specified on each servers SPUCHostService.exe (User Code Host Service), the default location is C:\ProgramData\Microsoft\SharePoint\UCCache
More Info:
http://blogs.msdn.com/b/sharepointdeveloperdocs/archive/2010/10/06/where-are-assemblies-in-sandboxed-solutions-deployed.aspx

SPMetal - Specified cast is not valid

Problem:  I am using LINQ to SharePoint to retrieve data.  A specific SPMetal list request generates the error "Specified cast is not valid".  Additional error information shown in the UI:
Web Part Error: Unhandled exception was thrown by the sandboxed code wrapper's Execute method in the partial trust app domain: An unexpected error has occurred.
From the stack trace:
"at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at Microsoft.SharePoint.UserCode.SPUserCodeWorkerProcess.ExecuteDelegate.EndInvoke(IAsyncResult result)"
Hypothesis: The error message is a standard error thrown in a SharePoint sandbox solution. The underlying issue is that the proxy is working on lists using SPMetal however only 1 list is causing the problem.  I remembered that I had altered the list using Powershell.   Obviously the entity proxy class generated is based on the old list.  Generate the proxy with the latest lists.
Resoultion: Run SPMetal again to correct the proxy code as the proxy classes do not match the backend SharePoint lists. 

Sandboxed Solution with Full Trust Proxy

Problem: You deploy code as a sandbox solution however it fails as you need to go beyond the permissions a sandboxed solution can perform.  For example sandbox solution code cannot write to the ULS and security is restricted so you won't be able to use RunWithElevatedPrivileges.

Resolution: You can develop a full trust proxy that is deployed into the GAC, you also need to register the full trust with SharePoint.  Lastly, create the code for your sandboxed solution using the Full Trust Proxy code.  The full trust proxy performs the operations that are beyond what the sandbox solution code is allowed to perform.
Update 23 April 2011 - CKSDev is an extension tool for Visual Studio that has a SPI (template) to create a full trust proxy.  This will do all the plumbing of creating the full trust proxy and the deployment packaging.  So if you are wanting to add a Sandbox Solution Full Trust Proxy for Logging use the VS template provide and all you need to add is your logging code.

More Info:
http://blah.winsmarts.com/2009-12-SharePoint_2010_Sandboxed_Solutions__Full_Trust__Proxies.aspx
http://ranvijaysingh.blogspot.com/2010/06/full-trust-proxy-in-sharepoint-sandbox.html

Deploying a Sandbox solution

Problem: I created several wsp packages, unfortunately 1 of the solution projects was marked as a Sandbox solution when the project was created in Visual Studio 2010.  The lookup lists are not deploying correctly in the sandbox solution because I deployed the solution at farm level.

Initial Hypothesis: I notice my lists had strange behaviour.  I check my deployment and 1 of the solutions had not been deployed.  When I deployed the wsp using Powershell (PS> Install-SPSolution ...) it did not error so I had presumed it had installed correctly.  Using PowerShell (PS) I could see the solution holding the list wasn't installed. PS> Get-Solution

Resolution: Retract the solution and remove it from the farm.  Deploy the solution to the Site Collection's solutions and enable the feature/s.  Powershell Commands:

PS> Add-SPUserSolution -LiteralPath D:\packages\.Lists.wsp -Site http://demo.dev

PS> Install-SPUserSolution –Identity Lists.wsp -Site http://demo.dev
PS> Enable-SPFeature –Identity Feature_GeneralLists –url http://demo.dev/

Tip: Update 10 Dec 2010 - If you remove a solution (this also applies to sandbox solutions) (including deactivating the associated features), if the feature deploys content types or site columns, you will need to do an IISreset if you want the content types and site columns removed from the Site Collection (alernatively restart the Web Application so the whole farm is not reset).

Post on deploying fasm wsp's.

Sandbox solution deployment error

Problem: Deploying a solution package to a sandboxed site using Visual Studio 2010 I receive the error "Error occurred in deployment step 'Activate Features': Timeout occurred while running the SharePoint Sandboxed Code service. This service is required to run sandboxed solutions in SharePoint.  Please ensure the service is configured correctly in SharePoint.". 
Resolution: I restarted my "SharePoint 2010 User Code Host" Windows Service.

More: Common error after initial install of SharePoint Error: Cannot start service SPUserCodeV4

http://www.sharepointdevwiki.com/display/spadmin2010/Configuring+Sandboxed+Solutions+-+Cannot+start+service+SPUserCodeV4+on+computer

Deploying to GAC vs bin folder in SP 2010

Problem: Do we deploy our to the GAC or the bin directory.

Answer: It depends on what the dll is, who needs to use it and is the SharePoint farm dedicated. You need to understand Code Access Security (CAS). Key point is dlls in the GAC (Global Assembly Cache) have full privileges. dll's in the bin have restricted privileges. You can change the level of permissions for dll's in the bin using CAS policies. SharePoint has 2 policys you can use by default: WSS_Minimal or WSS_Medium (same options as in MOSS). You can also use ASP.NET's policies, there are about 5 of these policies in .NET and the highest level is the "Full Trust" CAS policy. You can also create your own policy. Change the CAS relating to you dll's in the bin via your applications web.config.

Only code that runs in the IIS workprocess can be placed in the bin.  Deploying to the bin minimises permissios but certain tasks such as timer jobs, workflows, service applications and event receivers only work in the GAC.  Deploying to the GAC allows for multiple versions of the dll to exist in the GAC provided versioning is used.  Bin deployment can't have multiple versions.

Note on Sandboxed solutions - runs is the "Microsoft SharePoint Sandboxed Code Service", sandboxed solutions have restricted rights to what it can do. It can permorm basic SP Server side OM's unde the SPSite (Site collection) object under the current SPSite which makes sense. Sandboxed code is deployed to the solutions gallery under the current SPSite. You can also use sandboxed solutions with code proxyies to achieve higher rights operations.  So as you can see sandboxed solutions do not go into the GAC or the bin and CAS is not an issue.  Real option is between GAC + using a Sandbox solution.

Sandbox solutions are good in restricted high usage environments as they allow SharePoint Administrators to validate (manually and via solution validators) the code being uploaded.  Developers are limited in what they can do to the environment.  The counter stop inefficient code once the threshold has been passed.  Administrators can monitor sandboxed solutions to easily identify poorly performing code.

My general rule is: Deploy my custom code to the GAC except if it's not trusted i.e. 3rd party code or there is a business reason/policy not to. It makes dev easier but is not ideal in that best practice decitates that you should apply the minimal levels of security permissions to your code.
Additional Info: Microsoft SharePoint Team Blog on application development.
Great blog on sandboxed solutions