Thủ thuật Sharepoint 2010 part 54 potx

Solutions  359 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. 360  CHAPTER 13 UsiNg featUres aNd solUtioN Packages 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). Solutions  361 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. 362  CHAPTER 13 UsiNg featUres aNd solUtioN Packages 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). Solutions  363 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 364  CHAPTER 13 UsiNg featUres aNd solUtioN Packages 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 indicating 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 -lename 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 Solutions  365 The STSADM equivalent is: 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 366  CHAPTER 13 UsiNg featUres aNd solUtioN Packages 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 Solutions  367 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 les Total les: 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 368  CHAPTER 13 UsiNg featUres aNd solUtioN Packages 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 [...]... (Enable-SPFeature) or you can use the Manage Site Features user interface Summary As you have seen in this chapter, Features and Solutions are essential ways of adding functionality to SharePoint While there are other ways you can add functionality to SharePoint, those methods are not recommended Features and Solutions come with a host of useful options, tools, and commands that were designed to make your life as an . output. Install-SPSolution SampleWebPart.wsp -WebApplication http:/ /sharepoint Solutions  365 The STSADM equivalent is: STSADM -o deploysolution -name SampleWebPart.wsp -url http:/ /sharepoint To retract. 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. 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