Sandbox Solution (3)

Sandboxed solutions have access to a large subset of functionality in the Microsoft.SharePoint namespace. Essentially all the classes below SPSite are available. This means that SPSite, SPWeb, SPList, and SPListItem are all available. In a sandboxed solution, you can create Web Parts, list definitions and instances, content types and fields, modules, declarative workflows, and event receivers. As long as the object is within the Site Collection.

sandbox process prevents you from accessing data outside the site collection where the solution has been deployed.

For example:

You cannot: (very strict!!!!)

* you can’t access the Internet to make Web service calls
* you can’t access a hard drive to read or write files,
* you can’t access code that is not marked to allow partially trusted callers.
* you can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution, and security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed

You can:

* read and write to lists and libraries
within the same site collection
* allow enough function for site level.

At time, when you need to reach out of the box to do something thing, such as making web service calls:

(1) the best way is to use Business Connectivity Service (BCS) to create an external content type. You can then read and write to the data source from the sandboxed solution.
(2) Another way is to write a class that runs in a full-trust process outside the sandboxed worker process to proxy calls. This proxy class is deployed as a farm solution and is callable from the sandboxed solution.

For farm administrator to control quota on a site collections:

Farm admin can also adjust the quotas by using Windows Powershell:

Iterate through every site collection and reset the values back to their defaults. Using the Get-SPSite
command and piping it to a foreach statement changes all the values with a single line of code.
To run this code, open a SharePoint 2010 Management Console window from the Start menu and type the following commands:

Get-SPSite | foreach-object {$_.Quota.UserCodeMaximumLevel = 300}
Get-SPSite | foreach-object {$_.Quota.UserCodeWarningLevel = 100}

If you want to see only what the current quota values are, you can run the following PowerShell command:

Get-SPSite | foreach-object {$_.Quota}

UserCodeWarningLevel and UserCodeMaximumLevel are the two quota properties that control sandboxed solutions. You will see the terms “user code” and “user solutions” to refer to sandboxed code and solutions in some of the administration pages and in the SharePoint object model. SharePoint contains 14 metrics
that contribute to the quota points.

  1. AbnormalProcessTerminationCount
  2. CPUExecutionTime
  3. CriticalExceptionCount
  4. InvocationCount
  5. PercentProcessorTime
  6. ProcessCPUCycles
  7. ProcessHandleCount
  8. ProcessIOBytes
  9. ProcessThreadCount
  10. ProcessVirtualBytes
  11. SharePointDatabaseQueryCount
  12. SharePointDatabaseQueryTime
  13. UnhandledExceptionCount
  14. UnresponsiveprocessCount

    Each metric, called a ResourceMeasure, contains a ResourcesPerPoint property. The ResourcesPerPoint value is divided by the resources consumed to calculate the points used for that category. The default ResourcesPerPoint value is 3,600 for CPUExecutionTime.

    (CONTINUED on Sanbox Solution (4))

Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: