Sharepoint Sandbox Solutions v/s Sharepoint Farm Solutions

Introduction

Sandbox solutions: run code that only has the ability to affect the site collection of the solution and is hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe). The IIS application pool and IIS server do not need to restart since sandboxed solutions do not execute in the IIS worker process.

Farm solutions are hosted by the W3WP.exe worker process of Internet Information Services (IIS). A user's actions could affect the entire farm if they run any code in a farm solution. When a feature is deployed or withdrawn, the entire application pool is recycled.

Sharepoint Sandbox Solutions

A SharePoint application that has been sandboxed operates in a secure, closely-watched process with restricted access to the Web farm.Site collection-level changes can be deployed to SharePoint using sandbox solutions, which are customization packages. Any code that is present in a sandbox solution has been run in a unique, isolated process with a constrained set of APIs to access SharePoint services and content.

There are two types of Sandbox solutions

• Code-based sandbox solutions, which contain a custom assembly in the package.
• Declarative sandbox solutions, which only contain XML-based configurations and related assets.

Based on the following use cases, declarative (XML-based) sandbox systems can be further classified.

1. Site template: A template created by using an existing site's "Save site as a template" feature.
2. Design package: Produced by the publishing site's Design Manager.
3. Custom sandbox solutions: Created in Visual Studio for branding materials, which do not include assemblies.

According to their use cases, code-based sandbox technologies can be further classified into the following categories.

1. Solution for the Declarative Sandbox with an empty Assembly
2. Sandbox solution with a coded InfoPath form
3. Customizable code-based sandbox solutions with web components, event receivers, or feature receivers
4. Solutions in a sandbox with individualized workflows

Limitations of SharePoint Sandboxed Solutions

1. Site collection-level deployment (no farm- or web application-scoped features). As a result, if you have 100 site collections, you must install the same sandbox solution across all of them.
2. There is no SPSecurity, hence no elevated privileges
3. The SPSite object cannot be used to retrieve other site collections.
4. Visual web parts are not supported; however, you can acquire this feature by using the "Visual Studio 200 SharePoint Power Tools."
5. Is unable to call network resources. For instance, you cannot read or write to a server-side database (although you can use Silverlight)
6. Just "No code" workflows are permitted. There are no Visual Studio workflows (but those without classes that are imported and changed in Visual Studio will function nonetheless)!

Sharepoint Farm Solutions

In contrast to other Windows platforms and apps, SharePoint has its own method for adding extensions to administrative features. There is no use of an MSI file or ClickOnce technology. Instead, a single file known as a solution package is used to contain the assemblies, XML, and other items in the extension. A solution package has a .wsp file extension but a.cab-based format. SharePoint Features, all of their child components, as well as any components that aren't installed in Features, may be included in the package. The packages are uploaded by farm administrators to a farm-wide storage location, from which they may be deployed and have their Features turned on.

Farm solutions have code in them that is installed on SharePoint servers and communicates with the server object model. They are always operated with complete confidence. In addition to the website scope of the SharePoint Add-ins, the Features in farm solutions can also have a scope as broad as the site collection, web application, or entire farm. Farm administrators may be hesitant to install farm solutions because of these aspects unless the solutions are from a reputable and well-respected source. End-user-focused SharePoint extensions should be created as SharePoint Add-ins rather than farm solutions. Farm solutions should be utilized for customizing Central Administration, Windows PowerShell cmdlets, and timer jobs, among other administrative SharePoint features.

Difference Between Sandbox Solutions and Farm Solutions

One major difference in the deployment is Farm solutions are installed and deployed. Sandboxed solutions are uploaded and activated.

SharePoint Farm Solution

1. Farming solutions, which are hosted by the W3WP.exe IIS worker process, Run the program that has farm-wide implications.
2. When you debug a SharePoint project whose "farm solution" Sandboxed Solution property is set.
3. Before SharePoint retracts or deploys the functionality, the system's IIS application pool recycles to unlock any files that the IIS worker process has locked.
4. Only the IIS application pool that serves the site URL for the SharePoint project is recycled.
5. They have complete trust and access to all resources because they are viewed as being at the farm level.

SharePoint Sandbox Solution

1. Sandboxed solutions run code that can only have an impact on the site collection of the solution and are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe).
2. Neither the IIS application pool nor the IIS server needs to restart because sandboxed solutions don't execute in the IIS worker process.
3. The SPUCWorkerProcess process, which the SPUserCodeV4 service in SharePoint automatically initiates and manages, is attached to the debugger by Visual Studio.
4. Recycling the SPUC Worker process is not required in order to load the most recent version of the solution.
5. Selecting BuildDeploy Solution deploys the solution to the site collection Solution Gallery when the Sandboxed Solution property is set to True.

Conclusion

The structure of a sandbox solution is very similar to a farm solution, which generally runs with full-trust permissions. The main differences lie in how a sandbox solution is deployed and in the process that hosts the solution (which determines whether a solution is a sandboxed solution or a farm solution). This means that the same sandboxed solution can run with full trust when it’s deployed at the farm level and with partial trust when it’s deployed at the SharePoint site collection level.

An MS SharePoint solution is a deployable package that can contain features and assemblies. The solution package is a .cab-based file with a .wsp extension. Visual Studio 2010 SharePoint project templates create .wsp package files. A solution might contain a number of Microsoft SharePoint features, and these features provide functionality such as web parts, list definitions, modules, and event receivers.

 Which solution needs to be selected?

Sandbox solution is best for the following reasons.

• It will deploy at the site collection level rather than the farm level, so it allows us to this lets you separate a solution so it is only offered to one site collection within the farm.
• Sandboxed solutions also run in a separate process from the main SharePoint IIS web application process, and the separate process is throttled and monitored with quotas to guard the SharePoint site from becoming unresponsive due to a misbehaving sandboxed solution.
• Users can deploy solutions without requiring an administrator agreement.