Thủ thuật Sharepoint 2010 part 54 potx

SharePoint 2010 introduces a new type of Solution called a Sandbox Solution that allows Site Collection administrators to deploy and manage Solutions at the site collection level while

FIguRE 13-9 FIguRE 13-10

Of course, most Features that you will see in your life as a SharePoint administrator will be far more complex than the one you just created, but this should help give you an idea of what is involved in creating, installing, and activating a Feature in SharePoint

SOLutIONS

Solutions are nothing more than a properly formatted cab file that has a wsp extension, and they are the recommended way to deploy Features and any other functionality to SharePoint Though they differ in many ways, you can think of a wsp file in SharePoint as being very much like an msi file for Windows Both contain instructions for deploying content to their respective environments

SharePoint 2010 introduces a new type of Solution called a Sandbox Solution that allows Site

Collection administrators to deploy and manage Solutions at the site collection level while pro-viding the capability to throttle the amount of resources those Solutions use within the farm They are called Sandbox Solutions because their capabilities are constrained at runtime both from a security and functional standpoint Sandbox Solutions enable administrators to give users more freedom within their site collections, while also providing the ability for the administrator

to limit users’ impact on the farm

managing Farm Solutions

Managing Solutions is a lot like managing Features and other items in SharePoint With Solutions, you can manage their installation and deployment through the Central Administration user inter-face, and even more through the command line — whether it is with PowerShell or legacy STSADM commands

Managing farm solutions via the User interface

When managing Solutions in SharePoint, you can do almost anything through the user

inter-face The only normal actions that you cannot perform through the user interface are adding and updating Solutions in the farm solution store Essentially, everything else can be done through the browser When managing a Solution through the browser, you always begin in the same place: Select Central Administration➤➤➪➤➤System Settings➤➤➪➤➤Farm Management➤➤➪➤➤Manage farm solutions,

as shown in Figure 13-11

FIguRE 13-11

Deploying Solutions

To deploy a Solution using the user interface, we will start at the Solution Management page in Central Administration The Solution Management page, shown in Figure 13-12, gives you an over-view of all the Solutions in the farm, along with their deployment status and location

FIguRE 13-12

Here you can see that the samplewebpart.wsp Solution is not deployed To deploy the Solution, click the Solution name This will take you to the Solution Properties page, shown in Figure 13-13, which provides some basic information about the Solution, such as whether it contains web appli-cation resources, assemblies to be deployed in the global assembly cache (GAC), or a custom code access security policy, as well as previous operations and deployment status and deployment loca-tions (if any)

FIguRE 13-13

This page also contains a link labeled Deploy Solution Clicking this link takes you to the Deploy Solution page (see Figure 13-14) It is from this page that you take any actions needed to deploy the Solution, which include specifying when the Solution will be deployed and to where it will be deployed By default, Solutions are set to deploy immediately and to all content web applications, or globally if no web application resources are present Whether the Solution is set to deploy immedi-ately or at a scheduled time, the actual deployment action is a job scheduled with the Timer Service Given that, you can reasonably expect that the deployments will occur either close to now/immedi-ately or near the time specifi ed, but it will not be precise

In addition to specifying when the Solution should be deployed, you also specify where In cases for which no web application resources are part of the Solution, you will not have the option to specify where you would like to deploy the Solution That’s because any Solution that does not have a web application resource is considered to be a global Solution Examples of web application resources might be SafeControl entries destined for the web.config fi le or an assembly that is headed for the web application’s bin folder, to name only two Once you specify the deployment time, and the loca-tion if applicable, all you have to do is click OK and the deployment process will be scheduled

SafeControl entries provide the necessary registration information for custom

code that allows it to be executed in the SharePoint farm For example, these

type of entries are necessary for any new Web Parts that are created.

FIguRE 13-14

Retracting a Solution

To “undeploy” a Solution, simply retract it After a Solution has been deployed, access the Solution Properties page, where you will see a Retract Solution link next to the Deploy Solution link, as shown

in Figure 13-15 (Note that before the Solution was deployed, the link next to Deploy Solution was Remove Solution; this is covered in the next section.)

When you click the Retract Solution link, you are taken to the Retract Solution page, which is almost identical to the Deploy Solution page Again, you specify when you want the action to take place and

at what location Once the information has been specified and submitted, the job will be scheduled for the retraction to occur

Removing a Solution

You can remove a Solution only when the Solution is no longer deployed to a location When the Solution is no longer deployed, a Remove Solution link appears next to the Deploy Solution link, where the Retract Solution link used to be (see Figure 13-16)

FIguRE 13-15 FIguRE 13-16

When you click the Remove Solution link, you are prompted for confirmation; if confirmed, the Solution will be removed from the solution store Remember that Solutions cannot be added to the solution store through the user interface, so before removing a Solution, ensure that you have or can get access to SharePoint via PowerShell if you will need to add the Solution back later

Managing farm solutions via the Command line

Like Features, the command line provides all of the administrative functions needed to manage Solutions From the command line you can view information, add/remove/update Solutions from the solution store, and deploy/retract Solutions globally or to specific web applications

View Solution Information

The PowerShell cmdlet Get-SPSolution enables you to view basic information about a Solution Using the cmdlet without parameters, you can retrieve a list of all of the Solutions in the farm, as in the following example

Get-SPSolution

Name SolutionId Deployed

-samplewebpart.wsp 177004f5-c0ba-4f54-80d0-e2afb78d4865 False

If no Solutions are in the solution store the cmdlet will return nothing

You can retrieve a specific Solution by specifying a name, as in the following example

Get-SPSolution samplewebpart.wsp

Name SolutionId Deployed

-samplewebpart.wsp 177004f5-c0ba-4f54-80d0-e2afb78d4865 False

There is no STSADM equivalent for this command

Adding, Updating, and Removing Solutions

The capability to add and update Solutions is limited to the command line There is no out-of-the-box functionality that will allow you do it any other way Conversely, you can remove a Solution using either the command line or the user interface The commands used to add, update, and remove Solutions are Add-SPSolution, Update-SPSolution, and Remove-SPSolution, respectively

The following Add-SPSolution cmdlet is straightforward and takes a single parameter that indi-cates the path to the wsp file:

Add-SPSolution C:\SampleWebPart.wsp

Name SolutionId Deployed

-samplewebpart.wsp 177004f5-c0ba-4f54-80d0-e2afb78d4865 False

The STSADM equivalent command is:

STSADM -o addsolution C:\SampleWebPart.wsp

Updating a Solution is a little more involved, as it can require knowledge of the Solution itself The Update-SPSolution cmdlet has several parameters, some of which may be required depend-ing on the contents of the Solution In addition to the required attributes indicatdepend-ing the name of the Solution (-Identity) and the file path to the updated wsp file (-LiteralPath), you may be required to specify one or more of the following:

-CASPolicies

➤

➤ — If the Solution contains a custom code access security policy

-GACDeployment

➤

➤ — If the Solution contains assemblies that have a target deployment loca-tion of the GAC (Global Assembly Cache)

-Time

➤

➤ — If you would like to schedule the update (the default is immediate)

-Force

➤

➤ — If you need to bypass some of the safety checks that SharePoint uses

The Update-SPSolution cmdlet returns no output:

Update-SPSolution SampleWebPart.wsp -LiteralPath C:\SampleWebPart.wsp

The STSADM equivalent is:

STSADM -o upgradesolution -name SampleWebPart.wsp -filename C:\SampleWebPart.wsp

Removing a Solution is straightforward You simply call Remove-SPSolution with the name of the Solution There is one catch to using the Remove-SPSolution cmdlet: The Solution being removed cannot be deployed globally or to a web application unless you are willing to use the -Force param-eter (which, as you learned earlier, can leave things in an inconsistent state) The Remove-SPSolution

cmdlet returns no output:

Remove-SPSolution SampleWebPart.wsp

The STSADM equivalent is:

STSADM -o deletesolution -name SampleWebPart.wsp

Deploying and Retracting Solutions

The commands used to deploy and retract Solutions are named using a different nomenclature; they are Install-SPSolution and Uninstall-SPSolution, respectively The Install-SPSolution cmd-let has some of the same optional parameters as the Update-SPSolution cmdlet (-GACDeployment,

-CASPolicies, -Time), and they serve the same purpose The required parameters for the cmdlet are the name /identity of the Solution and the web application to which it should be deployed The web appli-cation parameter takes one of two forms: The -AllWebApplicaitons parameter instructs SharePoint

to deploy the Solution to all content web applications, whereas the -WebApplication parameter enables you to specify a specific web application for deployment The Install-SPSolution cmdlet returns no output

Install-SPSolution SampleWebPart.wsp -WebApplication http://sharepoint

STSADM -o deploysolution -name SampleWebPart.wsp -url http://sharepoint

To retract the Solution, use the following cmdlet:

Uninstall-SPSolution SampleWebPart.wsp -WebApplication http://sharepoint

The STSADM equivalent is:

STSADM -o retractsolution -name SampleWebPart.wsp -url http://sharepoint

managing Sandbox Solutions

There are two aspects to managing Sandbox Solutions: the administrator’s and the user’s An admin-istrator will manage settings for Sandbox Solutions from Central Administration The throttling capa-bility can be managed from the Site Quotas and Locks page, which is accessed from the Configure quotas and locks link in the Site Collections management section (see Figure 13-17)

FIguRE 13-17

When you navigate to the page, notice the section

toward the bottom, shown in Figure 13-18 Here you

can set the maximum number of points that a

Solution in the particular site collection can use

Points are a metric that is used to measure the

resources used by a Solution When the specified

threshold is surpassed, the Solution will not function

until the next day (after midnight)

creating Solutions

Creating a Solution in SharePoint is generally a straightforward task, but it can be a little tricky at times because you are editing text and XML files by hand (much like you did when creating a Feature) When creating a Solution by hand, you generally need to create two files:

manifest.xml and sharepoint.ddf The filename of the ddf file is not important, but the filename of the manifest must be manifest.xml As you have learned so far in this chapter, the manifest file is the instruction set that tells SharePoint what items are being provisioned

to the file system and elsewhere when the Solution is added to the solution store, as well as what items should be provisioned when deploying to a web application

The ddf file, however, has not been covered yet That’s because this file does not concern SharePoint in any way The ddf file is merely a means to an end — and that end is the creation of the Solution files (aka

the cab file) The ddf file is an instruction file for the MAKECAB.EXE utility that comes with Windows;

FIguRE 13-18

and, no surprises here, it makes a cabinet file based on the ddf file specified as one of the command-line parameters

For this example, you will be packaging the Feature you created earlier in the chapter into your Solution

1 Start by creating a directory structure to mimic your desired Solution file structure For this Solution, the desired structure will be pretty basic Begin by creating a directory named

MySolution The MySolution directory can be created anywhere on your system, but in this case you create it off of the C:\ drive

2 Inside the MySolution folder, create a folder named MyBasicMenuItem

(note that it is the same name that you created for your Feature) When

that is complete, you should have a structure that looks like the one shown

in Figure 13-19

3 Now that you have the directory structure, you want to add a manifest.xml file to the

MySolution directory Place the following XML inside that file:

<Solution SolutionId=”53C17DBB-EB22-48E2-B81D-B17EE68A9395”

xmlns=”http://schemas.microsoft.com/sharepoint/“>

<FeatureManifests>

<FeatureManifest Location=”MyBasicMenuItem\feature.xml”/>

</FeatureManifests>

</Solution>

Notice that the manifest file contains a unique identifier in the form of the SolutionId

attribute; and like a Feature’s Id attribute, the SolutionId is a GUID and should not be reused The manifest file can contain any of the items that are part of the Solution schema, but for this sample you only need to include a Feature manifest The Feature manifest sim-ply tells SharePoint where in the Solution file a Feature definition is located, and SharePoint will copy the entire directory from inside the Solution file to the TEMPLATE\FEATURES folder inside the SharePoint root

4 Now that you have the manifest file created, you need to add the Feature files into your struc-ture Copy the feature.xml and elements.xml files that you created earlier in this chapter

to the MyBasicMenuItem directory Once those files are copied, your Solution structure is complete and should resemble what is shown in Figure 13-20 and Figure 13-21

5 With the Solution structure and its contents complete, you are now ready to package the con-tents into a wsp file To do this, you need to create a ddf file that you can reference when calling the MAKECAB.EXE utility A ddf file is straightforward; it basically contains a listing of the files and directories that need to be included/created in the file You can visit the follow-ing link for more information on the MAKECAB.EXE utility: http://msdn.microsoft.com/ en-us/library/bb417343.aspx# microsoftmakecabusersguide Following are the con-tents of the ddf file you will use to package your Solution Name the file MySolution.ddf

and place it in the MySolution folder you created at C:\MySolution

manifest.xml Set DestinationDir=MyBasicMenuItem MyBasicMenuItem\feature.xml

MyBasicMenuItem\elements.xml

FIguRE 13-19

FIguRE 13-20

FIguRE 13-21

6 The file references are relative to the path from which the MAKECAB.EXE utility is run Execute the MAKECAB.EXE utility from the C:\MySolution directory as follows:

C:\MySolution>makecab /F MySolution.ddf /D

CabinetNameTemplate=MySolution.wsp /D DiskDirectory1=wsp

Cabinet Maker - Lossless Data Compression Tool

805 bytes in 3 files

Total files: 3

Bytes before: 805

Bytes after: 376

After/Before: 46.71% compression

Time: 0.09 seconds ( 0 hr 0 min 0.09 sec)

Throughput: 9.25 Kb/second

After the command completes successfully, you will have a newly created Solution fi le located at C:\MySolution\wsp\MySolution.wsp Remember that this is just an ordinary Cabinet fi le, so if you want to view the contents of the fi le all you have to do is rename the

fi le extension to cab and then you can view the contents with Windows Explorer or your favorite compression tool

Before moving forward with this part of the example, ensure that the Feature

from earlier in this chapter has been deactivated from any sites, uninstalled from

the farm, and its directory removed from the TEMPLATE\ FEATURES directory in

the SharePoint root.

7 With the Solution fi le created, you are ready to add the Solution to the solution store; and after that you can activate the MyBasicMenuItem Feature To install the Solution, use the

Add-SPSolution cmdlet you learned about earlier in the chapter:

PS C:\> Add-SPSolution C:\MySolution\wsp\MySolution.wsp

Name SolutionId Deployed -mysolution.wsp 4afc1350-f354-4439-b941-51377e845f2b False

8 Once the Solution has been successfully added to the solution store, it will need to be installed/deployed before the Feature is available for use To deploy the Solution, use the

Install-SPSolution cmdlet:

PS C:\> Install-SPSolution MySolution.wsp

You can verify the status of the Solution in the solution store by visiting the Solution Management page in Central Administration, as shown in Figure 13-22

FIguRE 13-22