Sandbox Solution (2)

http://msdn.microsoft.com/en-us/magazine/ee335711.aspx

Building a Sandbox Web Part

A sandboxed solution looks and behaves like a farm solution, but a sandboxed solution’s assembly must be marked to allow partially trusted callers.

Remember that a sandboxed solution can be deployed as a full-trust solution and gain the expanded capabilities that come with running in full trust because nothing in the .wsp solution file specifies it as a sandboxed solution or a farm solution. This is determined by how the solution is deployed.

Create a empty Sharepoint project, called testWebPart, sandbox solution. Add a web part to the project, default name WebPart1. Your web part is ready to deploy. VS deploys and activates the solutions in the Solution Gallery if you press F5.

*** As you can with other types of Visual Studio projects, you can set a breakpoint in the code for a sandboxed solution. However, Visual Studio won’t recognize a breakpoint at this point because the Web Part has not been added to a page. You’ll see an empty red circle in the left margin for the line of code that has the breakpoint, as shown in Figure 5, indicating that the assembly that contains the Web Part has not been loaded in the attached process. When you add the Web Part to a page, Visual Studio detects that the assembly has been loaded and will stop on the breakpoint.

Full-trust solutions run under the IIS worker process used by SharePoint called w3wp.exe. However, sandbox solution doesn’t. They run under the sandboxed worker process called SPUCWorkerProcess.exe. (VS attomatically attach the debugger to this process when you press F5)

Full trust solution – w3wp.exe
Sandbox solution – SPUCWorkerProcess.exe

If you’re debugging a solution that’s already deployed, you need to manually attach to this process. In VS 2010, Debug à Attach to Process


Examples —

Add the code to CreateChildControls method in the web part.

protected override void CreateChildControls()

{

base.CreateChildControls();

Label ListCount = new Label();

ListCount.Text =

String.Format(“There are {0} Lists”,

SPContext.Current.Web.Lists.Count);

Controls.Add(ListCount);

}

Build, deploy and add the web part to your web page, you should see this:

Now instead of inserting the above code, insert this now:

protected override void CreateChildControls()

{

base.CreateChildControls();

SPSecurity.RunWithElevatedPrivileges(

delegate

{

Label ListCount = new Label();

ListCount.Text =

String.Format(“There are {0} Lists”,

SPContext.Current.Web.Lists.Count);

Controls.Add(ListCount);

});

}

Deploy and refresh the page again, you will get an security error because SPSecurity class is not part of the sandboxed SharePoint API. Visual Studio compiles against the full version of the SharePoint API, but at runtime, SharePoint swaps out the full API for the sandboxed API, and this API is what your code runs against. Visual Studio can help you write valid code by filtering IntelliSense for you when you create a sandboxed solution.

(CONTINUED IN Sandbox (3))

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: