SharePoint Features consist of a Feature manifest file defining the Feature. The Feature files from the solution packages are automatically extracted into those. Features can be scoped at different levels, as shown in table 7. Activation can be done from the web interface, using administrative commands, or automatically by SharePoint. When using Features with your Web Parts, the Features should always be scoped at the site collection level. This is because the Web Part Gallery is located at the site collection level.
Activation of a Feature means that SharePoint reads the Feature manifest and goes through all the elements manifests within the Feature. These manifests are the actual content and actions that are applied to the scoped level. When deploying solution packages from Visual Studio , the Features will be activated by default. You can change this by editing the properties of the project and setting the Active Deployment Configuration option to No Activation.
Each Feature can also contain a Feature receiver. The Feature receiver is a class in an assembly that derives from the SPFeatureReceiver class and is used to programmatically perform actions on different events. This class has five event methods that are called on by SharePoint:. The runtime filter sample in chapter 5 used a Feature receiver to modify the web.
Feature receivers are compiled code and can do basically anything, and they can take advantage of the state and information in the currently targeted Feature scope. You can add receivers to the Feature by right-clicking the feature in the Solution Explorer and selecting Add Event Receiver, as shown in figure 7.
This will create a class under your Feature node that contains the receiver. The Feature receivers have two methods that can be used when the solution is installed in the farm. These methods are fired after the installation of the Feature in the farm, and the methods are run on each server in the farm.
The activation and deactivation methods are only run on one of the servers in the farm. If you want to make sure that the. Listing 7. The Feature receiver has one parameter, properties , containing information about the current Feature. Using that parameter, you get the current site collection. Using the root web GetCatalog method, you retrieve the Web part Gallery. The first item matching the name of the Web Part controls description file defined in the elements.
But because users can customize and add items to the Web Part Gallery, the filename might be changed or there might be multiple Web Parts defined in the gallery using the Web Part type. To ensure that all Web Part control description files in the Web Part Gallery that use the type of the Web Part defined in the Feature are removed, you need to change the deactivation method.
This method iterates through all items in the Web Part Gallery and checks the type used by the Web Part. Instead of finding a Web Part control description file by name, this method iterates all items in the gallery. For each item, it retrieves the SPFile object so that a stream can be opened and finally loaded into an XDocument object. The XDocument class is defined in the System. Linq namespace. The value of the attribute is used to create a Type object.
If this type is the same as the type of the Web Part class , the item is deleted. This method allows for a more generic approach of removing Web Part control description files from the gallery and avoiding erroneous Web Part definitions.
The downside of using deactivation code that removes the. In many situations you need to have configuration data for your solutions and Web Parts. For example, you might need database connection strings, web service endpoints, or other types of information. This property bag can be used to set default values for your Web Part. You add a property bag to a Feature by adding a new project item of the Empty Element type.
The property bag is defined inside the Elements element as shown here:. The property bag specifies that the properties should be promoted to the current SPWeb object and only on the root web.
The property bag contains one or more properties, each of which has a name, a type, and a value. When a Feature containing the element manifest is deployed and activated, it will add a new value to the property bag of the top-level web site of the site collection.
The values of the property bag are retrieved using the AllProperties hash table object on the SPWeb object like this:. Be cautious about what you store in these property bags. They can be accessed easily, even by sandboxed solutions. Safe controls are registered in the web.
The SafeControl entries are added to the web. Each Web Part will have its own SafeControl entry, by default. The SafeControl entry defines the assembly and namespace in which the Web Part exists. This attribute is used to prevent cross-site scripting XSS , which is the term used when malicious attackers try to inject client script code into a web page.
When the SafeAgainstScript attribute is set to false , only users with the Designer permission can insert the Web Part into a page or edit its custom properties. More specifically, the users need the Add and Customize Pages site permission, which the Designer permission level by default contains. Visual Studio automatically adds the necessary safe control information to the solution package when adding new Web Part SPI s to the project.
In the Properties window, select the Safe Control Entries row and click the ellipsis button. This opens a dialog box where you can edit the SafeControl entry for this Web Part, as shown in figure 7. You can also use this dialog box to edit the other values in the SafeControl entry or add new ones.
To enhance the security of Web Parts that are marked as Safe Against Script, you can add a specific attribute called RequiresDesignerPermission to those properties that you still want to disable for nondesigners, as shown here. The attribute is defined in the Microsoft. WebPartPages namespace and in this sample this namespace has the alias of SP :. The RequiresDesignerPermission attribute is used to indicate that this property can only be edited by those with Designer permission, even if the Web Part is marked as Safe Against Script in the web.
If you ever change the name of your Web Part which you probably will do more than once , you also need to make sure that you update the Safe Control entry.
Then the process of deploying the solutions in the test, staging, or production environment begins. You no longer have the ease of Visual Studio doing all the work for you with deploying and activating Features. PowerShell allows you to execute operations that are more advanced and scripting and automate the deployment process. When Visual Studio is used to build and debug Web Parts, the deployment process is automated.
The process can be configured using the deployment configurations in Visual Studio. The process can—and should be—scripted. You have a few options for making this deployment. PowerShell is the way to go with SharePoint Once the snap-in is loaded, you have access to all cmdlets in SharePoint. Deploying a solution requires that the WSP file is uploaded to the configuration database. When the cmdlet is done, it returns the status of the operation, as shown in figure 7.
The status includes the id of the solution and its deployment status. To retrieve a list of all installed solutions, use this command:. Many cmdlets are available for SharePoint and they often have many parameters that you can take advantage of. PowerShell helps you write the commands—you can press the Tab key to access command completion and you can use the get-help cmdlet to search for or get help for a specific cmdlet.
If you need to remove solutions that are deployed, you must specify the -Force parameter. The -Force parameter can, for instance, be used when you have exceptions thrown in your Feature uninstall receiver methods. There can be some confusion about the naming convention used in SharePoint. Deploying and installing is the same thing when it comes to solutions.
Deploy is the term used in the interface such as Central Administration , and install is the term used by PowerShell. The opposites are retract for the interface and uninstall in PowerShell. The same goes for Features. Features can be activated or deactivated in the web interface and enabled or disabled in PowerShell.
When the solution is uploaded into the farm, you must deploy it to use it. Deployment is accomplished using the Install-SPSolution cmdlet. This cmdlet takes a number of parameters. First, you need the name of your solution, which is the name of the WSP file. Because Web Parts are installed into a site collection, the name of the web application hosting the site collection is needed.
The solution could be installed on all web applications by specifying the -AllWebApplications parameter, which includes Central Administration.
But I recommend that you always specify which web applications you want to install your solutions in. This command will deploy the solution to the specified server and register the assembly in the GAC. The deployment can be verified using the Get-SPSolution cmdlet. To retract deployed solutions you use the Uninstall-SPSolution command like this:. This command uninstalls the solution from the specified web application. You can set the install and uninstall cmdlets to be executed at specific times.
The examples presented so far are all performed immediately. Uninstallation and upgrades require that the application pools be recycled. This means that the web applications will be unavailable for a short period and current requests may be aborted. In scenarios when there are high availability requirements, all install and uninstall commands must be coordinated during specific support hours.
These processes are called application pools and they can host one or more web applications. In SharePoint, the Central Administration website runs in its own application pool and the content web applications run in one or more application pools. When the solutions are installed on staging or production servers, you need to activate the Features manually. Features can be activated in the user interface and, depending on its scope, in different places, as you can see in table 7. They can also be activated and managed using PowerShell.
Also, I find it helpful as a developer and architect to create scripts as an aid to the administrators and for myself. This command will give you the name, id, and scope of all installed Features in the farm. Most often, you have many Features installed so you can use PowerShell features to search the output from a cmdlet:.
This command will retrieve all Features installed and then filter out those that begin with WebPartsInAction. The result will be printed as a list using the Format-List command with only the display name instead of the default table format. The pipe character sends the result of the previous command into the next one.
Studying PowerShell and using features like this can be valuable. You can call Get-SPFeature with different scope parameters to show only the activated Features in that scope. To get the currently activated Features on a specific site collection, use this command:. This cmdlet takes the name of the Feature and the URL where it should be activated. Deactivating a Feature is similar to activating it. PowerShell can take a while to learn, but it will be all worth it in the end.
The advanced functions take the administration experience to a whole new level. Suppose you have a large farm with thousands of site collections. Please provide additional feedback optional :. Cancel Submit. You are using Microsoft Internet Explorer! Microsoft no longer supports this browser. As a result, some of the functionality on this website may not work for you.
For an optimal experience on our website, please consider changing to Microsoft Edge, Firefox, Chrome or Safari. Article Languages. Translated Content Please note that this document is a translation from English, and may have been machine-translated. Fill in your details below or click an icon to log in:. Email required Address never made public. Name required. Follow Following.
Vignesh's SharePoint Thoughts Join other followers. Sign me up. Already have a WordPress. Log in now.
0コメント