In this demo will show:Use VS 2010 to create sandbox solutions.Deploy and configuration on the Sandbox solutions.Test deploy the sandbox solution.Go through the prerequisites to enable user code service on your farm. Enable User code service in your farm-- Tips: Don’t use WSP Builder menu for Sandbox solutions, use Retract,Deply…etc options from the Project properties menu.Try to do a change in UI and redeploy your wsp, the old webpart UI still cached, Resolve: Remove the webpart from webpart gallery.
Inert: Not effectiveIt’s called also : Sandbox Solution model process: 4 phases: Upload stageActivation stageDeactivation stage: pages with web parts will shows an error message.Delete Stage: cant be deleted if the solution is activated. If deleted it goes to the site recycle bin and can be deleted or restored.Upgrade Stage
Activate/ Deactivate/ Delete and restore.
Path for the configuration for the sandbox solution is:C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14CONFIGFile name: wss_usercode.config
How to get VS 2010 SP power tools:From VS tools -> Extension manager and Top Ranked Extensions.
Open SPSNYCDemo2Try to build - > Get an error since the SPSecurity in not available in sandbox solutions.Change the project target to farm solution and try to build -> 0 errors.This is only applied on: VS 2010 Power tools. This is your validation for Sandbox solutions.Details:http://visualstudiogallery.msdn.microsoft.com/en-us/8e602a8c-6714-4549-9e95-f3700344b0d9
To show how to load balance the sandbox solutions:Central AdministrationSystem SettingsManage User Solutions All user requests will be executed on the same machine - >Users’ requests are routed using solution affinity.Try to blocksharepoint solution and navigate to the webpart page. You will see the block message is appearing.
Only 14 metric:http://msdn.microsoft.com/en-us/magazine/ee335711.aspx
From Central admin -> application management -> Configure quotas and locks
2. Agenda<br />Sandbox Solutions Overview<br />SharePoint 2007 Challenges for Farm Solutions<br />SharePoint 2010 Approach for Sandbox Solutions<br />Sandbox Solutions Lifecycle<br />Executing Code in the Sandbox<br />Sandbox Solutions Limitations<br />Sandbox Resource Monitoring<br />Load balancing Sandbox solutions<br />Solution Validation<br />
3. Overview of the Sandbox<br />Allows a subset of the full capabilities in the SharePoint API<br />Secure – enforcing the sandbox<br />Execute in a partially trusted environment<br />Code executes in a special service process<br />Subject to CAS<br />Validation framework<br />Provides way to do custom farm wide validation for the deployed packages<br />Each solution is isolated to its site collection<br />
5. SharePoint 2007 Challenge<br />Developers build custom solutions<br />Administrators can only secure solutions with CAS<br />Hard to control what is being done in custom code<br />Biggest cause of SharePoint support cases: custom code<br />
6. SharePoint 2010 Approach<br />Developers build custom solutions<br />Site collection owners deploy, activate and implement the customizations<br />Administrators leverage resource monitors to check site collection usage<br />Automatic triggers “turn off” custom solutions in a site collection that are too expensive and taxing on the server<br />
7. Sandboxed Solutions Help Enterprises<br />Sandboxed solutions are important because<br />Hosted environments much easier to manage<br />Reduces time to deploying custom solutions<br />Removing process of getting code approved and deployed by IT (Dev-Staging-Production)<br />Improves stability of SharePoint servers<br />Now badly performing code isolated to site collection rather than potentially bringing down an entire server<br />
13. The Subset Object Model<br />SPSite<br />In general<br />SPSite and below<br />No SPSecurity<br />No SPSite construction<br />Common namespaces not available<br />Microsoft.SharePoint.Administration<br />Microsoft.SharePoint.WebControls<br />SPWeb<br />SPList<br />SPListItem<br />
14. A Separate Process<br />User Code Service : Started where WFE configured to run sandbox solutions.(SPUCHostService.exe)<br />Sandbox Worker Process: where your actual code runs(SPUCWorkerProcess.exe)<br />Sandbox Worker Process Proxy(SPUCWorkerProcessProxy.exe)<br />
19. Best Practices: Sandbox Boundaries <br />Off-box connections, http, web services, etc<br />ADO.net<br />Enterprise features (Search, BCS, etc.)<br />Threading (No complex processing)<br />P-Invoke<br />IO<br />Other sites<br />x<br />x<br />x<br />x<br />x<br />x<br />x<br />
20. Compiling vs. Executing Sandboxed Solutions<br />Visual Studio 2010uses IntelliSense tohide full-trust types<br />All code is compiled against the full API<br />Thus, no “sandbox” check at compile time… only at runtime<br />Workaround: change the Microsoft.SharePoint.dll project reference to reference the sandbox’s version<br />[..]14UserCodeAssembliesMicrosoft.SharePoint.dll<br />NOTE: Switch it back before deployment!<br />Use this as a temporary test - do not deploy code that references the sandbox’s assembly<br /> This is valid if you don’t have VS 2010 SP Power tools.<br />MyWebPart.dll<br />Runtime<br />Full Object Model<br />Subset Object Model<br />Proxy<br />
21. Execution vs. Compilation in Sandbox<br />Demo <br />
22. Load Balancing<br />Sandboxed solutions can be run in two modes<br />Local Mode<br />Execute code on the SharePoint WFE<br />Low administration overhead<br />Lower scalability<br />Remote Mode<br />Execution on back-end farm machine<br />Via dedicated service applications<br />Load balanced distribution of code execution requests<br />