Why should I use Resources?

In my opinion, you should always use resource files for your features. Why?

• First, because it’s easy to do even if you only have one language.
• Second, because if you do, all the objects you are provisioning in SharePoint will be localized and will be displayed in the correct language of the website (provided you have deployed the resource file for that language).

Examples of things that should be placed in resource files:

• Title and Description of you feature, so that they will be displayed in the language of the website;
• Site column display name and description;
• Content type name and description;
• List template name and description;
• List instance title and description;
• Custom action title and description.

How do I use it?

There are three steps to use resources in a feature:

1. Build the resource (.resx) files;
2. Place the resource files in the correct folder;
3. Use the resource strings in the feature manifest and element manifests.

Note: The next sections show how to use feature-specific resources. I’ll briefly discuss shared resources in the end of the post.

Building the resource (.resx) files

The best way to build the resource files is using Visual Studio 2008, but you can do it manually on any text editor since they’re just XML text files.

<?xml version="1.0" encoding="utf-8"?>
<root>
  <resheader name="resmimetype">
    <value>text/microsoft-resx</value>
  </resheader>
  <resheader name="version">
    <value>2.0</value>
  </resheader>
  <resheader name="reader">
    <value>
      System.Resources.ResXResourceReader, 
      System.Windows.Forms, 
      Version=2.0.0.0, 
      Culture=neutral, 
      PublicKeyToken=b77a5c561934e089
    </value>
  </resheader>
  <resheader name="writer">
    <value>
      System.Resources.ResXResourceWriter, 
      System.Windows.Forms, 
      Version=2.0.0.0, 
      Culture=neutral, 
      PublicKeyToken=b77a5c561934e089
    </value>
  </resheader>
  <data name="MyFeatureName" xml:space="preserve">
    <value>My Feature Name</value>
  </data>
  <data name="MyFieldDisplayName" xml:space="preserve">
    <value>My Field Display Name</value>
  </data>
  <data name="MyFieldChoice1" xml:space="preserve">
    <value>My Choice 1</value>
  </data>
  <data name="MyFieldChoice2" xml:space="preserve">
    <value>My Choice 2</value>
  </data>
</root>

See above an example of a resource (.resx) file. The <data> elements are the ones that hold the localized strings:

• The name attribute is the key used to retrieve the localized string;
• The <value> child element is the localized string itself.

Each language must have its own resource file which follows a specific naming convention:

• The main resource file must be called Resources.resx. This is the culture neutral resource file (or fall back resource file) which will be used by SharePoint whenever there is no resource file for a specific culture.
• All culture specific resource files must be named Resources.[culture].resx. Some examples:
  • Resources.en-US.resx (english – United States)
  • Resources.pt-PT.resx (portuguese – Portugal)
  • Resources.fr-FR.resx (french – France)
  • Resources.pt-BR.resx (portuguese – Brazil)

Placing the resource files in the correct folder

These files must be placed in a Resources folder inside your feature’s folder. So, if your feature’s folder is C:\…\12\TEMPLATE\FEATURES\MyFeature, the resource files need to be placed in the folder C:\…\12\TEMPLATE\FEATURES\MyFeature\Resources.

Resources and the Feature Manifest

After you have created the resource files and placed the in the correct folder, you can now used them in your feature manifest (feature.xml).

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="$Resources:MyFeatureName"
         Scope="Site"
         Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="SiteColumns.xml"/>
    <ElementFile Location="Resources\Resources.resx" />
    <ElementFile Location="Resources\Resources.pt-PT.resx" />
    <ElementFile Location="Resources\Resources.es-ES.resx" />
  </ElementManifests>
</Feature>

The sample above, shows a feature manifest that uses resources to specify the feature title. As you can see, the value of the Title attribute is $Resources:MyFeatureName. This tells SharePoint that it should check the resource file for the current website’s culture and retrieve the string that has the key MyFeatureName.

Notice the use of <ElementFile> elements to reference the resource files in the feature. This is required if you are deploying this feature through a solution package (.wsp).

Important: because we are using feature-specific resource files (resource files that are only used for this specific feature), you cannot use the DefaultResourceFile attribute on the <Feature> element. If you do, SharePoint will not look for resource files in the local Resources folder for this feature.

Resources and the Element Manifest

Besides using localized strings to specify the feature title and description, you can (and should) use localized strings for most feature elements.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Field Type="Choice"
         DisplayName="$Resources:MyFieldDisplayName"
         Required="FALSE"
         Format="Dropdown"
         FillInChoice="FALSE"
         ID="{485b2176-4cfc-4923-8085-c003b85dab36}"
         StaticName="MyField"
         Name="MyField">
    <Default>$Resources:MyFieldChoice1</Default>
    <CHOICES>
      <CHOICE>$Resources:MyFieldChoice1</CHOICE>
      <CHOICE>$Resources:MyFieldChoice2</CHOICE>
    </CHOICES>
  </Field>
 </Elements>

The sample above specifies a choice field, and uses localized strings for:

• Field display name
• Each of the field’s choices
• The field’s default choice

The theory is exactly the same as it was used for the feature manifest: you use the expression $Resources:[key] whenever you want SharePoint to retrieve a localized string from the resource file of the current website’s culture.

Shared Resource Files

The method shown in the previous sections assumed that each feature has its own resource files. However, that is not always the case and SharePoint itself uses shared resource files. That is, resource files that can be shared by multiple features.

There are only two differences when using shared resource files:

• The folder where the resource files are placed;
• The way you reference the localized string in you feature manifest and element manifests.

Other than that, the file format and contents can be exactly the same.

Folder for Shared Resources

Shared resource files must be placed in the folder C:\…\12\Resources instead of the local Resources folder inside the feature folder.

Referencing Shared Resources

Because the shared resources files can have any name you want, you must reference the localized strings in a more specific way, so as to tell SharePoint which resource file holds a particular string.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="$Resources:MyResources,MyFeatureName"
         Scope="Site"
         Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="SiteColumns.xml"/>
  </ElementManifests>
</Feature>

As you can see in the above sample, instead of $Resources:MyFeatureName I’m referencing the localized string with $Resources:MyResources,MyFeatureName. This tells SharePoint to look for:

• A localized string whose key is MyFeatureName
• In a resource file named MyResources.[Culture].resx
• In the C:\…\12\Resources folder

If all your strings are in the same shared resource file, then you can specify that file as the default resource file and reference the strings as shown in the first sample.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="$Resources:MyFeatureName"
         DefaultResourceFile="MyResources"
         Scope="Site"
         Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="SiteColumns.xml"/>
  </ElementManifests>
</Feature>

The sample above does exactly the same as the previous one. The only difference is that it specifies MyResources.[culture].resx as the default resource file and, because of that, you don’t need to specify it on all references to the localized strings.

Additional Notes

So, how does SharePoint choose which resource file to use when loading the localized strings?

1. Looks for the resource file of the exact culture of the website. If you have a website based on a portuguese (pt-PT) site template, it will look for the Resources.pt-PT.resx. If it’s there, it loads all the strings from it.
2. If it’s not there, it looks for any resource files of the same culture, even if it has a different location. So if your website’s language is pt-PT (Portuguese – Portugal) and you don’t have a Resources.pt-PT.resx file, but you have a Resources.pt-BR.resx (Portuguese – Brazil) file, then SharePoint will use it.
3. If there is no resource file for the website’s culture, SharePoint will use the fall back resource file (Resources.resx).

Samples

You can download samples for:

• Feature with Local Resources
• Feature with Shared Resources

These samples include:

• The solution manifest file (manifest.xml).
• The solution cab structure file (solution.ddf).
• The feature manifest file (Feature.xml).
• The element manifest file (SiteColumns.xml).
• The resource files (.resx)
• A batch file (build.bat) that creates the solution package

Warning: Do not install both solutions in the same farm, since some of the IDs are the same and the feature has the same name on both solutions. If you want to use it as is, test each solution separately, removing one before installing the other.

Notice: These samples are given for illustrative purposes only. Feel free to modify and use them as templates for your solutions and features.

The post SharePoint 2007 Deployment: Using Resources in Features appeared first on Blog IT.

This post is about developing features that associate other features to an existing site definition. This is one of the most powerful types of feature since it allows you to add new functionality to existing site definitions. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the feature stapling (feature site template association).

You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Feature Stapling

Feature stapling is the process of associating features to existing site definitions so that, when a new site is provisioned from that definition the associated features are automatically activated.

This means that you need, at least, two features to do this:

• The feature (or features) you wish to associate (that is, to staple) to a site definition;
• The feature that performs the association (the stapler).

The first one can be any feature with scope Site or Web. The second is the one I’m presenting in this post.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with feature site template association elements can be deployed to Site Collection, Web Application or Farm scopes.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{8213A053-46B0-43f9-B00C-B2A8CF7A3355}"
    Title="My Feature Stapling"
    Description="This feature staples other features to a
    site definition."
    Scope="Farm"
    Creator="Create IT"
    Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="Elements.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Feature Stapling.
• It will be deployed as a Farm feature, since it’s Scope value is Farm. By default, SharePoint automatically activates features of this scope. You can, however, override this behaviour by setting the ActivateOnDefault attribute to false on the Feature element.
• It references a single element manifest file: Elements.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it’s called Elements.xml), but it’s root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <FeatureSiteTemplateAssociation> element which is used to associate features to existing site definitions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- My Site Columns -->
  <FeatureSiteTemplateAssociation 
    Id="{CC3144A5-E055-4474-928E-5D21CDE53D38}" 
    TemplateName="STS#0" />
  <!-- My Content Types -->
  <FeatureSiteTemplateAssociation 
    Id="{E739683D-ACB8-4187-A764-1323BE76D12D}" 
    TemplateName="STS#0" />
</Elements>

This example associates two features with the Team Site definition. The <FeatureSiteTemplateAssociation> element has no child elements and only two attributes:

• Id – (required) The GUID of the feature that is to be stapled to the site definition.
• TemplateName – (required) The name of the site definition including the configuration Id. For SharePoint’s out-of-the-box site definitions, this attribute can be:
  • STS#0 (Team Site)
  • STS#1 (Blank Site)
  • STS#2 (Document Workspace)
  • MPS#0 (Basic Meeting Workspace)
  • MPS#1 (Blank Meeting Workspace)
  • MPS#2 (Decision Meeting Workspace)
  • MPS#3 (Social Meeting Workspace)
  • MPS#4 (Multipage Meeting Workspace)
  • CENTRALADMIN#0 (Central Administration)
  • WIKI#0 (Wiki Site)
  • BLOG#0 (Blog Site)
  • BDR#0 (Document Center)
  • OFFILE#1 (Records Center)
  • SPSMSITEHOST#0 (My Site Host)
  • SPSMSITE#0 (Personalization Site)
  • CMSPUBLISHING#0 (Publishing Site)
  • BLANKINTERNET#2 (Publishing Site with Workflow)
  • BLANKINTERNETCONTAINER#0 (Publishing Portal)
  • SPSPORTAL#0 (Collaboration Portal)
  • SPSNHOME#0 (News Site)
  • SPSITES#0 (Site Directory)
  • SPSREPORTCENTER#0 (Report Center)
  • SRCHCEN#0 (Search Center with Tabs)
  • SRCHCENTERLITE#0 (Search Center)

There can be other site definitions depending on which site templates you have installed on your farm. The best way to check which ones you can use is to go to the folder C:\…\12\TEMPLATE\[LCID]\XML where [LCID] represent the Language ID of the site definition you are looking for, and open each webtemp*.xml file.

Each of these files will have the following structure:

<?xml version="1.0" encoding="utf-8"?>
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<Templates xmlns:ows="Microsoft SharePoint">
  <Template Name="STS" ID="1">
    <Configuration ID="0" 
                   Title="Team Site" 
                   Hidden="FALSE" 
                   ImageUrl="/_layouts/images/stsprev.png" 
                   Description="A site for teams to quickly […] 
                   DisplayCategory="Collaboration" >          
    </Configuration>
    <Configuration ID="1" 
                   Title="Blank Site" 
                   Hidden="FALSE" 
                   ImageUrl="/_layouts/images/blankprev.png" 
                   Description="A blank site for you to […] 
                   DisplayCategory="Collaboration" 
                   AllowGlobalFeatureAssociations="False" >      
    </Configuration>
    <Configuration ID="2" 
                   Title="Document Workspace" 
                   Hidden="FALSE" 
                   ImageUrl="/_layouts/images/dwsprev.png" 
                   Description="A site for colleagues to work[…] 
                   DisplayCategory="Collaboration" >          
    </Configuration>
    [...]
  </Template>
</Templates>

In the sample above you can see the description of the three configurations of the STS site template. To build the TemplateName required for the feature site template association, you get the template name (attribute Name of the element Template), which in this case is STS, add a hash sign (#) and complete the string with the configuration ID (attribute ID of the element Configuration), which in this case can be 0, 1 or 2, depending on the chosen configuration.

Sample

You can download this sample here. This sample includes:

• The solution manifest file (manifest.xml).
• The solution cab structure file (solution.ddf).
• The feature manifest file (Feature.xml).
• The feature site template association element manifest file (Elements.xml).
• A batch file (build.bat) that creates the solution package (MyFeatureStapling.wsp).

Notice: This sample is given for illustrative purposes only. Feel free to modify and use it as a template for your solutions and features.

The post SharePoint 2007 Deployment: Feature Stapling appeared first on Blog IT.

This post is about developing features to bind content types to lists that were provisioned through an onet.xml file. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the binding of content types.

You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Content Type Binding

When you provision a list through a feature, using the method explained in the post SharePoint 2007 Deployment: List Template Features, you can bind a content type to it only by editing the schema.xml file of the list template.

However, if the list was provisioned through a site definition (onet.xml file) and you had no access to its definition, you must do it using a Content Type Binding feature element. This can only be used to attach a content type to a list provisioned through a site definition.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with content type binding elements can only be deployed to a Site Collection scope.

Attempting to install a feature of another scope that contains content type binding elements, will result in an error.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{ACDECF85-BDF7-446c-AC1B-C5F133C83F15}"
    Title="Content Type Binding"
    Description="This feature binds a content type to the masterpage
gallery."
    Scope="Site"
    Creator="Create IT"
    Version="1.0.0.0">
  
  <ElementManifests>
    <ElementManifest Location="ContentTypeBinding.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is Content Type Binding.
• It will be deployed as a Site Collection feature, since it's Scope value is Site.
• It references a single element manifest file: ContentTypeBinding.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called ContentTypeBinding.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <ContentTypeBinding> element which is used to binding Content Types to list definitions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentTypeBinding
    ContentTypeId="0x010101"
    ListUrl="_catalogs/masterpage" />
</Elements>

This example binds the content type Form (which has the ID 0x010101) to the master page gallery (which has the URL _catalogs/masterpage). There <ContentTypeBinding> element has no child elements, and only two attributes:

• ContentTypeId – (required) The ID of the content type that will be bound to a list.
• ListUrl – (required) The URL of the list to which the content type will be bound.

Additional Notes

The content type will be bound to the list definition as soon as the administrator activates this feature on a site collection. However, deactivating the feature will not remove the connection between the content type and the list. If you wish to remove it, you must do so manually.

Sample

You can download this sample here. This sample includes:

• The solution manifest file (manifest.xml).
• The solution cab structure file (solution.ddf).
• The feature manifest file (feature.xml).
• The content type binding element manifest file (ContentTypeBinding.xml).
• A batch file (build.bat) that creates the solution package (ContentTypeBinding.wsp).

Notice: This sample is given for illustrative purposes only. Feel free to modify and use it as a template for your solutions and features.

The post SharePoint 2007 Deployment: Content Type Binding Features appeared first on Blog IT.

This post is about developing features to register event receivers. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the registration of event receivers.

Additionally, you must include the assembly that contains the event receiver class in the solution package, so that it gets deployed to the Global Assembly Cache. Follow the instructions in the post SharePoint 2007 Deployment: Creating Solutions on how to package these three files (both manifests plus the assembly file) on a SharePoint Solution file.

Events Receivers

SharePoint allows you to handle several events that are fired according to actions performed on items, lists and web sites. Event are handled through event receivers, which are classes that implement a method for each event that is handled.

Once an event receiver is developed, compiled into an assembly and deployed to the GAC, it must be registered to a content type, a list or a web site in order to handle its events. That can be done through the API (or third-party tool such as Event Handler Explorer) or, concerning item and list event receivers, through this type of feature.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with event registration elements can only be deployed to Web Site scopes.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{282902FB-0369-4f98-93C5-7FD7121CE164}"
    Title="My Event Receiver"
    Description="This feature registers My Event Receiver."
    Scope="Web"
    Creator="Create IT"
    Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="EventReceivers.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Event Receiver.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: EventReceivers.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called EventReceivers.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Receivers> element which is used to register event receivers that will handle list events.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Receivers 
    ListTemplateId="3500" 
    ListTemplateOwner="{11663D54-6152-4532-ABF5-FC08FAC216A7}">
    <Receiver>
      <Assembly>
        MyEventReceiver, 
        Version=1.0.0.0, 
        Culture=Neutral, 
        PublicKeyToken=6c0c7604915f786e
      </Assembly>
      <Class>MyEventReceiver.MyEventReceiver</Class>
      <Name>My Event Receiver</Name>
      <Type>ItemAdded</Type>
      <SequenceNumber>10000</SequenceNumber>
    </Receiver>
  </Receivers>
</Elements>

The example above registers an event receiver to all lists based on list template with ID 3500 that was deployed by a feature with the ID {11663D54-6152-4532-ABF5-FC08FAC216A7}. The receiver is the MyEventReceiver.MyEventReceiver class included in the assembly MyEventReceiver.dll that is installed in the GAC, and it handles the ItemAdded event on these lists.

The Receivers Element

The <Receivers> element is used to specify the list template to which the event receiver will be registered. There can be any number of <Receivers> elements in a single element manifest file. Here is a summary of the possible attributes of this element:

• ListTemplateId – (required) Specifies the ID of the list template to which the event receiver will be registered. If you wish to register an event receiver to one of SharePoint’s list templates, you can use one of the following values:
  • 100 – Generic List
  • 101 – Document Library
  • 102 – Survey
  • 103 – Links List
  • 104 – Announcements List
  • 105 – Contacts List
  • 106 – Events List
  • 107 – Tasks List
  • 108 – Discussion Board
  • 109 – Picture Library
  • 110 – Data Sources
  • 111 – Site Template Gallery
  • 112 – User Information List
  • 113 – Web Part Gallery
  • 114 – List Template Gallery
  • 115 – XML Form Library
  • 116 – Master Pages Gallery
  • 117 – No-Code Workflows
  • 118 – Custom Workflow Process
  • 119 – Wiki Page Library
  • 120 – Custom grid for a list
  • 130 – Data Connection Library
  • 140 – Workflow History
  • 150 – Gantt Tasks List
  • 200 – Meeting Workspace Series List
  • 201 – Meeting Workspace Agenda List
  • 202 – Meeting Workspace Attendees List
  • 204 – Meeting Workspace Decisions List
  • 207 – Meeting Workspace Objectives List
  • 210 – Meeting Workspace text box
  • 211 – Meeting Workspace Things To Bring List
  • 212 – Meeting Workspace Pages List
  • 301 – Blog Posts List
  • 302 – Blog Comments List
  • 303 – Blog Categories List
  • 1100 – Issue Tracking
  • 1200 – Administrator Tasks List
• ListTemplateOwner – (optional) Specifies the GUID of the Feature where the list template is defined, or the name of the site definition that registered the list.

The Receiver Element

The <Receiver> element specifies which class implements the event receiver and which list event it handles. There can any number <Receiver> child elements inside a <Receivers> parent element. This element has no attributes, but has six child elements, which are listed below:

• Assembly – The strong name of the assembly that contains the event receiver class. The strong name is composed of the name of the assembly (without the .dll extension), followed by a comma and the assembly version, followed by a comma and the assembly culture, followed by a comma and the assembly’s public key token.
• Class – The name of the class (including the namespace) that contains the implementation of the event receiver.
• Name – The name of the event receiver. This value is used to identify it if you wish to retrieve it through the API.
• Type – The event that the event receiver handles. Possible values are:
  • ContextEvent – The list received a context event.
  • EmailReceived – The list received an e-mail message.
  • FieldAdded – A field was added to the list.
  • FieldAdding – A field is being added to the list.
  • FieldDeleted – A field was removed from the list.
  • FieldDeleting – A field is being removed from the list.
  • FieldUpdated – A field was updated in the list.
  • FieldUpdating – A field is being updated in the list.
  • ItemAdding – An item is being added to the list.
  • ItemAdded – An item was added to the list.
  • ItemAttachmentAdded – An attachment was added to an item.
  • ItemAttachmentAdding – An attachment is being added to an item.
  • ItemAttachmentDeleted – An attachment was removed from an item.
  • ItemAttachmentDeleting – An attachment is being removed from an item.
  • ItemCheckedIn – An item was checked-in in the list.
  • ItemCheckingIn – An item is being checked-in in the list.
  • ItemCheckedOut – An item was checked-out in the list.
  • ItemCheckingOut – An item is being checked-out in the list.
  • ItemDeleted – An item was removed from the list.
  • ItemDeleting – An item is being removed from the list.
  • ItemFileConverted – A file was converted.
  • ItemFileMoved – A file was moved.
  • ItemFileMoving – A file is being moved.
  • ItemUncheckedOut – An item was unchecked-out in the list.
  • ItemUncheckingOut – An item is being unchecked-out in the list.
  • ItemUpdated – An item was updated in the list.
  • ItemUpdating – An item is being updated in the list.
• SequenceNumber – Specifies the order of the event receiver when more than one handler is associated with the same event. A high sequence number (10000 or higher) should be used to prevent problems with SharePoint’s own event handlers.
• Data – Specifies a string that will be passed as a parameter to the receiver method when handling the event.

Sample

You can download this sample here. This sample includes:

• The solution manifest file (manifest.xml).
• The solution cab structure file (solution.ddf).
• The feature manifest file (feature.xml).
• The event receiver element manifest file (EventReceivers.xml).
• A fake assembly (MyEventReceiver.dll) that must be replaced by your own assembly. Important: this file is not a real assembly containing an event receiver class, hence it will not work if deployed as is to your Sharepoint environment.
• A batch file (build.bat) that creates the solution package (MyEventReceiver.wsp).

Notice: This sample is given for illustrative purposes only and it should not be used as is in your SharePoint environment. Feel free to modify and use it as a template for your solutions and features.

The post SharePoint 2007 Deployment: Event Registration Features appeared first on Blog IT.

One of the most exciting features included in SharePoint 2007 is workflow support and the possibility of developing our own custom workflows (for more information about workflow development in the SharePoint 2007 platform please click here).

While it is possible to develop workflows to automate a series of activities without any human intervention, the full power of workflows in the SharePoint platform can only be achieved with human-oriented workflows. These workflows are characterized by creating and assigning tasks to users that must complete them in order to fulfill the purpose of the workflow. Some examples of out of the box human-oriented workflows that are included with MOSS 2007 are Approval, Collect Feedback and Issue Tracking.

In the SharePoint world, the most common usage of human-oriented workflows is in the context of document libraries, to perform some work when a new document is uploaded into a document library. Typically, in such scenario, tasks are created and assigned to users throughout the workflow lifetime that will complete them until the workflow purpose has been fulfilled. Having the workflow goal to be achieved is the desired and most common scenario, but unexpected actions may occur before the end of the workflow such as a user to delete the document. The following example will show you how to handle this situation in a custom workflow by using the OnWorkflowItemDeleted activity.

Example

The OnWorkflowItemDeleted activity can be used within a custom workflow to handle an item deletion in any SharePoint list. In this example, this activity will be used to delete all uncompleted tasks associated with the deleted item. After dragging and dropping the OnWorkflowItemDeleted activity into the workflow designer, the Invoke property must be set to the event handler that will perform the work.

For the purpose of this example, please consider the simple approval workflow in the following image:

In this workflow, a parallel activity with two branches is used. One contains the main workflow logic while the other contains a OnWorkflowItemDeleted activity that will handle the item deletion. The Invoke event property was set to be handled by an event handler method called OnWorkflowItemDeleted_Invoked. Let’s take a look at the code:

public sealed partial class ApprovalWorkflow : SequentialWorkflowActivity
{
    /// <summary>
    /// Handles the workflow item deleted event.
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private void OnWorkflowItemDeleted_Invoked(object sender, ExternalDataEventArgs e)
    {
        //delete uncompleted tasks when 
        //an item is deleted
        SPWorkflow workflowInstance = 
            workflowProperties.Workflow;
        SPWorkflowTaskCollection taskCollection = 
            GetWorkflowTasks(workflowInstance);
        for (int i = taskCollection.Count; i > 0; i--)
        {
            SPWorkflowTask task = 
                taskCollection[i - 1];
            using (SPWeb web = 
                workflowProperties.Web)
            {
                if (task[SPBuiltInFieldId.TaskStatus]
                    .ToString() != SPResource.GetString
                    (new CultureInfo((int)web.Language, false),
                    "WorkflowTaskStatusComplete", new object[0]))
                {
                    task.Delete();
                }
            }
        }
    }

    /// <summary>
    /// Reads the workflow tasks. This method 
    /// is implemented because the Tasks property
    /// of the SPWorkflow instance takes a 
    /// while to be populated.
    /// </summary>
    public static SPWorkflowTaskCollection 
        GetWorkflowTasks(SPWorkflow workflowInstance)
    {
        SPWorkflowTaskCollection taskCollection = null;
        bool tasksPopulated = false;
        while (!tasksPopulated)
        {
            try
            {
                taskCollection = workflowInstance.Tasks;
                tasksPopulated = true;
            }
            catch { }
        }

        return taskCollection;
    }
}

In the previous example, the following actions are being performed:

• In the OnWorkflowItemDeleted_Invoked event handler, the workflow instance task collection is obtained by calling the GetWorkflowTasks method;
• The task collection is iterated and the each task status is checked to verify if it is still uncompleted;
• If so, the task is deleted.

The post SharePoint 2007 Workflow – Using the OnWorkflowItemDeleted activity appeared first on Blog IT.

One of the areas where the SharePoint 2007 platform (both WSS 3.0 and MOSS 2007) still needs to improve is deployment despite all the major improvements made when compared to its antecessor, the 2003 version. One of the faults I ran recently into is related with updating list content types event handlers when site content types event handlers are updated.

For those who don’t know, let’s start by a brief introduction about content types and explain the difference between a site content type and a list content type. Content types are a new concept introduced in SharePoint 2007 and is basically a reusable collection of settings that can be applied to a certain category of content. Content types basically define the metadata (they are composed by a reusable set of columns called site columns) and behaviors (event handlers, workflows, etc) of a certain category of content. They are stored centrally and are reusable throughout a site or site collection depending on its scope. For more information about content types please click here.

So what is the difference between a site content type and a list content type? Probably, the easiest way to explain this is to think of site content types as templates (in the sense that they are reusable) and list content types as instances of those templates. Site content types are defined at the site level and are visible to the site where they are created and all its subsites (this concept is called content type scope) and they are reusable and not bound to any specific list, meaning that they can be associated with any list within the sites under its scope. When a site content type is associated with a list, a copy of the site content type is copied into the list, creating a new instance. This instance is called a list content type.

Example

The best approach to deploy content types is to use features (for more information about deploying site content types as a feature please click here). Registering content type event handlers can also be achieved using a feature (check this article for more information) or by using Patrick Tisseghem’s Event Handler Explorer. The problem is when there are already list content types based on a site content type and we need to add a new event handler to it and have all list content types also updated. In my experience, both using the feature model approach or using Patrick’s application didn’t update the list content types. The remainder of this post will show you how to do this programmatically.

The following example basically uses a console application to register a event handler and associate it to a content type.

class Program
{
    private const string URL = "http://myIntranet";
    private const string CONTENT_TYPE = "MyContentType";
    private const string EVENT_RECEIVER_NAME = "MyEventReceiver";
    private const string EVENT_RECEIVER_ASSEMBLY =
        "MyEventReceivers.MyEventReceiver, MyEventReceiver, " +
        "Version=1.0.0.0, Culture=neutral, PublicKeyToken=5989549632a535cf";
    private const string EVENT_RECEIVER_CLASS_NAME = 
        "MyEventReceivers.MyEventReceiver";

    static void Main(string[] args)
    {
        //open site collection
        using (SPSite siteCollection = new SPSite(URL))
        {
            using (SPWeb site = siteCollection.OpenWeb())
            {
                //get content type
                SPContentType contentType = 
                    site.ContentTypes[CONTENT_TYPE];
                // add ItemUpdating event handler
                ContentTypeHelper.AddEventHandler(contentType, 
                    EVENT_RECEIVER_NAME, EVENT_RECEIVER_ASSEMBLY, 
                    EVENT_RECEIVER_CLASS_NAME, 10000, 
                    SPEventReceiverInstallerType.ItemUpdating);

                site.Update();
            }
        }
    }
}

internal class ContentTypeHelper
{
    /// <summary>
    /// Register an event handler in a list
    /// </summary>
    /// <param name="contentType">SharePoint Content Type</param>
    /// <param name="receiverName">Event receiver name</param>
    /// <param name="className">Event handler class name</param>
    /// <param name="sequenceNumber">Sequence number</param>
    public static void AddEventHandler(SPContentType contentType, 
        string receiverName, string assemblyName, 
        string className, Int32 sequenceNumber, 
        SPEventReceiverInstallerType eventReceiverInstallerType)
    {
        //get assembly full name
        string assemblyFullName = System.Reflection.Assembly
            .GetAssembly(Type.GetType(assemblyName)).FullName;

        // remove existing event handlers
        RemoveEventHandlers(contentType, assemblyFullName);

        SPEventReceiverDefinition receiverDefinition = null;

        //ItemAdding event handler
        if (SPEventReceiverInstallerTypeHelper.CheckOption
            (eventReceiverInstallerType, 
            SPEventReceiverInstallerType.ItemAdding))
        {
            // add ItemAdding event handler
            receiverDefinition = contentType.EventReceivers.Add();
            receiverDefinition.Name = receiverName;
            receiverDefinition.Type = 
                SPEventReceiverType.ItemAdding;
            receiverDefinition.Assembly = assemblyFullName;
            receiverDefinition.Class = className;
            receiverDefinition.SequenceNumber = sequenceNumber;
            receiverDefinition.Update();
        }

        //ItemAdded event handler
        if (SPEventReceiverInstallerTypeHelper.CheckOption
            (eventReceiverInstallerType, 
            SPEventReceiverInstallerType.ItemAdded))
        {
            // add ItemAdded event handler
            receiverDefinition = contentType.EventReceivers.Add();
            receiverDefinition.Name = receiverName;
            receiverDefinition.Type = 
                SPEventReceiverType.ItemAdded;
            receiverDefinition.Assembly = assemblyFullName;
            receiverDefinition.Class = className;
            receiverDefinition.SequenceNumber = sequenceNumber;
            receiverDefinition.Update();
        }

        //ItemUpdating event handler
        if (SPEventReceiverInstallerTypeHelper.CheckOption
            (eventReceiverInstallerType, 
            SPEventReceiverInstallerType.ItemUpdating))
        {
            // add ItemUpdating event handler
            receiverDefinition = contentType.EventReceivers.Add();
            receiverDefinition.Name = receiverName;
            receiverDefinition.Type = 
                SPEventReceiverType.ItemUpdating;
            receiverDefinition.Assembly = assemblyFullName;
            receiverDefinition.Class = className;
            receiverDefinition.SequenceNumber = sequenceNumber;
            receiverDefinition.Update();
        }

        //ItemUpdated event handler
        if (SPEventReceiverInstallerTypeHelper.CheckOption
            (eventReceiverInstallerType, 
            SPEventReceiverInstallerType.ItemUpdated))
        {
            // add ItemUpdating event handler
            receiverDefinition =contentType.EventReceivers.Add();
            receiverDefinition.Name = receiverName;
            receiverDefinition.Type = 
                SPEventReceiverType.ItemUpdated;
            receiverDefinition.Assembly = assemblyFullName;
            receiverDefinition.Class = className;
            receiverDefinition.SequenceNumber = sequenceNumber;
            receiverDefinition.Update();
        }

        //ItemCheckingIn event handler
        if (SPEventReceiverInstallerTypeHelper.
            CheckOption(eventReceiverInstallerType, 
            SPEventReceiverInstallerType.ItemCheckingIn))
        {
            // add ItemCheckingIn event handler
            receiverDefinition = contentType.EventReceivers.Add();
            receiverDefinition.Name = receiverName;
            receiverDefinition.Type = 
                SPEventReceiverType.ItemCheckingIn;
            receiverDefinition.Assembly = assemblyFullName;
            receiverDefinition.Class = className;
            receiverDefinition.SequenceNumber = sequenceNumber;
            receiverDefinition.Update();
        }

        //ItemCheckedIn event handler
        if (SPEventReceiverInstallerTypeHelper.CheckOption
            (eventReceiverInstallerType, 
            SPEventReceiverInstallerType.ItemCheckedIn))
        {
            // add ItemCheckedIn event handler
            receiverDefinition = contentType.EventReceivers.Add();
            receiverDefinition.Name = receiverName;
            receiverDefinition.Type = 
                SPEventReceiverType.ItemCheckedIn;
            receiverDefinition.Assembly = assemblyFullName;
            receiverDefinition.Class = className;
            receiverDefinition.SequenceNumber = sequenceNumber;
            receiverDefinition.Update();
        }

        //update content type - setting the updateChildren 
        //parameter to true will update list content types
        contentType.Update(true);
    }

    /// <summary>
    /// Remove an event handler registration from a list.
    /// </summary>
    /// <param name="list">SharePoint list</param>
    /// <param name="receiverClass">Event receiver class name</param>
    internal static void RemoveEventHandlers(
        SPContentType contentType, 
        string receiverClass)
    {
        SPEventReceiverDefinition receiverDefinition = null;

        // cycle through all the receiver definitions and 
        //delete the receiver with the supplied class name
        for (int i = contentType.EventReceivers.Count - 1;
            i >= 0; i--)
        {
            receiverDefinition = contentType.EventReceivers[i];
            if (receiverDefinition.Class == receiverClass)
            {
                receiverDefinition.Delete();
            }
        }
    }
}

The statement that does the trick is "contentType.Update(true);" in the end of the AddEventHandler method. Setting the updateChildren parameter of this method to true will update list content types.

The post SharePoint 2007 – Updating List Content Types Event Handlers on Site Content Type Update appeared first on Blog IT.

This post is about developing features to deploy files in a SharePoint site (module features). Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the provisioning of files (modules) in a SharePoint site.

You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Modules

Modules are collections of files that must be provisioned in a SharePoint web site. This type of feature element can be used to:

• Add pages to a web site
• Add web parts to a web site’s web part gallery
• Add web parts to a web part page
• Add documents to a document library
• Add style sheets to the a web sites style library

According to the documentation, WSS 3.0 supports provisioning a maximum of 1000 files through module feature elements (whether using a single module element with 1000 files, or 1000 module elements each with a single file).

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with module elements can be deployed to Site Collection and Web Site scopes, since they represent files that are to be placed in web sites.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
  xmlns="http://schemas.microsoft.com/sharepoint/"
  Title="My Module Feature"
  Id="17E94729-EF3E-4f43-9385-88E1201F91E0"
  Description="This feature adds files to the web site."
  Version="1.0.0.0"
  Scope="Web"
  Hidden="FALSE"
  DefaultResourceFile="core">
    <ElementManifests>
        <ElementManifest Location="Modules.xml" />
        <ElementFile Location="default.aspx" />
        <ElementFile Location="MyMasterPage.master" />
        <ElementFile Location="MyDocument.docx" />
        <ElementFile Location="MyWebPart\MyWebPart.webpart" />
        <ElementFile Location="MyStyles.css" />
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Module Feature.
• It will be deployed as a Web Site feature, since it’s Scope value is Web.
• It references a single element manifest file: Modules.xml.
• It references several element file files. You must reference separately, using these elements, each file you wish to include in the module.

Element Manifest

The element manifest file can have any name you wish (in this example it’s called Module.xml), but it’s root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Module> element which is used to deploy Files to SharePoint web sites.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    
    <!-- Page Module -->
    <Module Name="Pages" Url="" Path="">
        <File Url="default.aspx" 
              NavBarHome="True" 
              IgnoreIfAlreadyExists="TRUE" 
              Type="Ghostable">

            <!-- Places Web Part on Page -->
            <AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
                <![CDATA[
                  <webParts>
                    <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
                      <metaData>
                        <type name="MyWebPart, 
                                    MyWebPart.MyWebPart, 
                                    Version=1.0.0.0, 
                                    Culture=neutral, 
                                    PublicKeyToken=1255988569cf0248" />
                        <importErrorMessage>
                            Cannot import My Web Part.
                        </importErrorMessage>
                      </metaData>
                      <data>
                        <properties>
                          <property name="Title" type="string">
                            My Web Part
                          </property>
                        </properties>
                      </data>
                    </webPart>
                  </webParts>
                ]]>
            </AllUsersWebPart>
            
            <!-- Places a List View for a Discussion Board -->
            <View List="Lists/Discussions" 
                  BaseViewID="4" 
                  Name="Discussions" 
                  WebPartZoneID="Left" 
                  WebPartOrder="2"/>

            <!-- Places a List View for a Document Library -->
            <View List="MyDocuments" 
                  BaseViewID="10" 
                  Name="My Documents" 
                  WebPartZoneID="Left" 
                  WebPartOrder="3"/>

            <!-- Customizes Navigation -->
            <NavBarPage Name="$Resources:core,nav_Home;" 
                        ID="1002" 
                        Position="Start" />
        </File>
    </Module>
    
    <!-- Master Page Module -->
    <Module Name="Master Pages" List="116" Url="_catalogs/masterpage">
        <File Url="MyMasterPage.master" Type="GhostableInLibrary" />
    </Module>

    <!-- Document Module -->
    <Module Name="Documents" List="101" Url="MyDocuments">
        <File Url="MyDocument.docx" Type="GhostableInLibrary" />
    </Module>

    <!-- Web Part Module -->
    <Module Name="WebParts" List="113" Url="_catalogs/wp">
        <File Path="MyWebPart\MyWebPart.webpart"
              Url="MyWebPart.webpart"
              Type="GhostableInLibrary" />
    </Module>

    <!-- Style Sheet Module -->
    <Module Name="Stylesheets" List="101" Url="Style Library">
        <File Url="MyStyles.css" Type="GhostableInLibrary" />
    </Module>
</Elements>

The example above provisions five different files in a SharePoint web site:

• An ASPX web page (web part page) to the root of the web site. This web page contains:
  • A MyWebPart Web Part (on web part zone Left)
  • A List View Web Part that shows a view of a discussion board list
  • A List View Web Part that shows a view of a document library
• A Master Page to the Master Page Gallery of the web site
• A document to a Document Library of the web site
• A web part to the Web Part Gallery of the web site
• A style sheet to the Style Library of the web site

The Module Element

The <Module> element is used to specify a Module. There can be any number of modules in a single element manifest. Here is a summary of the possible attributes of this element:

• IncludeFolders – (optional) I could figure out what this attribute is for…
• List – (optional) Type of list where the files included in this module should be provisioned (check the possible values on my post about List Template Features).
• Name – (required) Name of the module (file set).
• Path – (optional) Specifies the physical path of the files, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). By default, SharePoint assumes the files are in the same folder as the element manifest file. You can also specify the path on each <File> element (see below).
• RootWebOnly – (optional) Boolean value. If TRUE it specifies that the files in this module will only be provisioned on the root web site of a site collection.
• SetupPath – (optional) Specifies the physical path to a folder, inside SharePoint’s setup folder (C:\Program Files\...\12\TEMPLATE), that contains the files included in the module.
• Url – (optional) Specifies the virtual path of the folder in which to place the files of the module. This attribute is also used to provision a folder inside a list. If the Path is not specified, the value of this attribute will be used for the physical path also.

The File Element

The <File> element is used to specify a file inside a module. There can be any number of <File> elements inside a <Module> element. See below a list of the possible attributes of this element:

• IgnoreIfAlreadyExists – (optional) Boolean value. If TRUE it specifies that the file should be provisioned even if it already exists on the destination URL.
• Name – (optional) Specifies the virtual path for the file.
• NavBarHome – (optional) Boolean value. If TRUE it specifies that the file will be the destination of the Home link, used in the web site’s navigation. This attribute is only used for web pages.
• Path – (optional) Physical path to the file, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). This attribute is used if you need to specify a different path for each file inside the module. Otherwise, you can use the Path attribute on the Module element.
• Type – (optional) Specifies if the file is to be stored in a Document Library (in this case the value should be GhostableInLibrary) or outside of a list (in this case the value should be Ghostable).
• Url – (required) Specifies the virtual path for the file. If Name is specified, then the value of this attribute is ignored. However, if Path is not specified, the value of this attribute will be used for the physical path.

The AllUsersWebPart Element

The <AllUsersWebPart> element is used when you want to add a generic web part (non-List View web part) to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has only two attributes:

• WebPartOrder – (required) Specifies the vertical position of the web part inside a web part zone.
• WebPartZoneID – (required) Specifies the name of the web part zone.

Inside this element, you can place a CDATA element with the web part’s XML description, either using the DWP file schema (also called V2) or the WEBPART file schema (also called V3).

The View Element

The <View> element is used when you want to add a List View Web Part to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has a lot of possible attributes, but I will only list the most common:

• List – (optional) Specifies either the template type of the list (an integer value) or the URL of a list provisioned in the web site (a string value). On most cases, you should use the URL, since there might be two lists of the same type on the web site.
• BaseViewID – (optional) Specifies the ID of the list view to be used.
• Name – (optional) Specifies the name of the view.
• WebPartOrder – (required) Specifies the vertical position of the web part inside a web part zone.
• WebPartZoneID – (required) Specifies the name of the web part zone.

The NavBarPage Element

The <NavBarPage> element is used to define how the navigation items should be created so that other pages link to this one. It can only be used inside a <File> element that provisions a web page file. It has three attributes:

• ID – (required) Specifies the ID for the page. This ID will be used by other pages when defining the relative position of the navigation items.
• Name – (required) Specifies the text that is displayed in the navigation area of other pages that link to this one.
• Position – (optional) Specifies the position of the navigation item on the navigation area of other pages that link to this one. This attribute can have the following possible values:
  • Start – Add the node to the start of the top navigation area.
  • End – Add the node to the end of the top navigation area.
  • Number between 1001 and 2000 – Add the node after another NavBarPage element whose ID matches the number.

The Property Element

The <Property> element is used only inside the <File> element, to define the value of one or more properties of that file, once it is provisioned. It’s mostly used to set properties of web part files or document files. It has only two attributes:

• Name – (required) Name of the property to be set.
• Value – (required) Value to set the property with.

Additional Notes

The files included in a module feature element are provisioned in the web site where the feature is activated. However, when the feature is deactivated, the files that belong to the module element are not removed.

You can learn a lot about modules by looking inside the onet.xml files included in each site template (look in C:\Program Files\...\12\TEMPLATE\SiteTemplates). These files include a <Modules> element which shares the same schema as the Module Features.

The post SharePoint 2007 Deployment: Module Features appeared first on Blog IT.

Most navigation options on a SharePoint web site are manipulated through the SPWeb object’s property bag. Set the following properties to configure a web site’s navigation settings:

• __IncludeSubSitesInNavigation: Set this property to True to show the subsites of the current site on the global and current navigation menus. Set it to False to hide the subsites.
• __IncludePagesInNavigation: Set this property to True to show the pages on the global and current navigation menus. Set it to False to hide the pages.
• __InheritCurrentNavigation: Set this property to True to display the same navigations items as the parent site in the current navigation menu. Set it to False to display only items from the current site and subsites.
• __NavigationShowSiblings: Set this property to True to display the navigation items below the current site and the current site’s siblings, in the current navigation menu.
• __NavigationOrderingMethod: Set this property to one of the following values:
  • 0: Sort the navigation items automatically
  • 1: Sort the subsites manually but the pages automatically
  • 2: Sort the navigation items manually
• __NavigationAutomaticSortingMethod: When using automatic ordering, set this property to one of the following values:
  • 0: Sort by Title
  • 1: Sort by Created Date
  • 2: Sort by Last Modified Date
• __NavigationSortAscending: When using automatic ordering, set this property to True if the automatic sorting of the navigation items should be done in ascending order. Set it to False to use descending order.

Note: there are two underscore characters (_) in each property name.

Example
In the example below, I’m setting the navigation options to:

• Show only the current site’s navigation items in the global navigation
• Show the current site’s sub sites in the global navigation
• Don’t show the pages in the global navigation
• Show only the current site’s navigation items in the current navigation
• Don’t show the current site’s siblings in the current navigation
• Sort the navigation items manually

// break inheritance of global navigation
web.Navigation.UseShared = false;

// show subwebs but don't show pages in global navigation
web.AllProperties["__IncludeSubSitesInNavigation"] = "True";
web.AllProperties["__IncludePagesInNavigation"] = "False";

// show only current site's navigation items in current navigation
web.AllProperties["__InheritCurrentNavigation"] = "False";
web.AllProperties["__NavigationOrderingMethod"] = "2";
web.AllProperties["__NavigationShowSiblings"] = "False";
web.Update();

The post SharePoint Tip #24: Changing a Web Site’s Navigation Settings appeared first on Blog IT.

• Active Directory directory services
• LADP Directory (other than Active Directory)
• Databases and web services, via Business Data Catalog
• Custom sources, via the User Profiles object model

You can also add users to it manually. Additionally, you can add custom properties to the User Profile and map some of them to the data sources you have. This great flexibility allows a multitude of scenarios. In this post I'll show you how you can get access a User Profile programmatically.

Everything is starts with the UserProfileManager object. Here is how you use it to get a UserProfile object.

// open a site collection
using (SPSite site = new SPSite("http://myportal"))
{
    // get the server context
    ServerContext context = ServerContext.GetContext(site);

    // create the profile manager object
    UserProfileManager profileManager = new UserProfileManager(context);

    // get the user profile
    UserProfile profile = profileManager.GetUserProfile("domain\\username");
}

There constructor for the UserProfileManager class is overloaded, which means there are other ways to create an instance but this is the way I usually do it. The GetUserProfile method is also overloaded, allowing you to get a user profile using its ID or just getting the current user's profile.

Attention: User Profiles are a MOSS only feature. You cannot use them with WSS.

The post SharePoint Tip #20: Get User Profile appeared first on Blog IT.

This post is about developing features to create action features in a SharePoint site. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the creation of custom actions in a SharePoint site.

You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Custom Actions

Custom actions are links, toolbar buttons and menu items that you can add to or hide from the SharePoint’s user interface. Each custom action exists in a specific location, and depending on that location, can be a part of a group of actions.

With a custom action feature, you can:

• Add a new Custom Action Group which can be used to group custom actions in a specific options screen;
• Add a new Custom Action which can be a new option in a settings screen, a new menu item, or a new toolbar button;
• Hide an existing Custom Action whether that action is the result of custom action feature or it belongs to SharePoint’s out-of-the-box features.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with custom action elements can be deployed to all the scopes, that is, Farm, Web Application, Site Collection and Web Site.

The correct scope must be chosen according to the group and location of the custom action being added or hidden. Note that you can’t mix feature elements with different scopes on the same feature.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="My Custom Action Feature"
         Description="Adds Custom Actions to the Web Site."
         Scope="Web"
         Version="1.0.0.0">
    <ElementManifests>
        <ElementManifest Location="CustomActions.xml"/>
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Custom Actions Feature.
• It will be deployed as a Web Site feature, since it’s Scope value is Web.
• It references a single element manifest file: CustomActions.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it’s called CustomActions.xml), but it’s root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of three feature elements:

• <CustomActionGroup> used to create new custom action groups;
• <CustomAction> used to create new custom actions;
• <HideCustomAction> used to hide existing actions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <!-- Custom Action Group -->
    <CustomActionGroup
        Id="MyActionGroup"
        Description="This group contains all my custom actions."
        Title="My Action Group"
        Location="Microsoft.SharePoint.SiteSettings"
        Sequence="30" />

    <!-- Custom Action in Custom Action Group -->
    <CustomAction
        Id="MyCustomAction"
        Description="This link is a custom action."
        Title="My Custom Action"
        GroupId="MyActionGroup"
        Location="Microsoft.SharePoint.SiteSettings"
        Rights="ManageWeb"
        RequireSiteAdministrator="FALSE"
        Sequence="20">
        <UrlAction Url="~sitecollection/_layouts/MyCustomPage1.aspx" />
    </CustomAction>

    <!-- Custom Action in Site Actions Menu -->
    <CustomAction
        Id="MyNewCustomAction"
        Description="This menu item is a new custom action."
        Title="My New Custom Action"
        GroupId="SiteActions"
        Location="Microsoft.SharePoint.StandardMenu"
        ImageUrl="/_layouts/MyActionIcon.jpg"
        Sequence="10">
        <UrlAction Url="~sitecollection/_layouts/MyCustomPage2.aspx" />
    </CustomAction>

    <!-- Hide Custom Action -->
    <HideCustomAction
        Id="HideDeleteWeb"
        GroupId="SiteAdministration"
        Location="Microsoft.SharePoint.SiteSettings"
        HideActionId="DeleteWeb" />
</Elements>

The <CustomActionGroup> Element

The <CustomActionsGroup> element is used to create custom action groups that can contain custom actions. In the sample above, a new custom action group, named My Action Group, is added to the Site Settings screen.

The following attributes can be used with this element:

• Id – (optional) Specifies a unique identifier for this group. It can be a GUID or a unique term, for example "SiteManagement".
• Description – (optional) Description for the custom action group.
• Title – (required) Title of the custom action group, shown to the user in the UI.
• Location – (required) Specifies the place where the custom action group will be placed
  • Microsoft.SharePoint.SiteSettings – Site Settings screen
  • Microsoft.SharePoint.ContentTypeSettings – Content Type Settings screen
  • Microsoft.SharePoint.Administration.Operations – Operations screen in the Central Adminstration web site
  • Microsoft.SharePoint.Administration.ApplicationManagement – Application Management screen in the Central Administration
• Sequence – (optional) Order of the custom action group in the list of groups that exist in the specified location.

The <CustomAction> Element

The <CustomAction> element is used to create a new custom action in the UI. In the above samples, two custom actions are created:

• A custom action (named My Custom Action) in a custom action group (named My Action Group) in the Site Settings screen.
• A custom action (named My New Custom Action) in an existing action group (which is the Site Actions menu).

The following attributes can be used with this element:

• Id – (optional) Unique identifier to the custom action. The ID can be GUID or unique term, for example, "MyCustomAction".
• Description – (optional) Description for the custom action. It will be displayed as a tooltip or sub-description for the action, depending on its location.
• Title – (required) Title for the custom action.
• GroupId – (optional) Specifies an action group inside which to place the custom action. If this custom action is contained inside a custom action group, the value of this attribute must match the value of the Id attribute of the <CustomActionGroup> element.
• Location – (required) Specifies the location for this custom action. If this custom action is contained inside a custom action group, the value of this attribute must match the value of the Location attribute of the <CustomActionGroup> element. Check the possible values below, in the Locations and Group IDs section.
• ImageUrl – (optional) Address of the image to use as the icon for this custom action. Note that, in certain locations, the custom actions don’t have an icon.
• Rights – (optional) Specifies a set of permissions that the user must have in order for the link to be visible. If omitted, the action always appears. To specify multiple values, separate them using commas (which means the user must have all the permissions specified). Check the possible values below, in the Action Rights section.
• RequireSiteAdministrator – (optional) TRUE to specifiy that the user must be a site administrator to see the custom action. The default value is FALSE. This attribute is not supported if the custom action is to be placed in the context menu for a list item.
• Sequence – (optional) Specifies the order of the custom action inside its action group.
• ContentTypeId – (optional) Specifies the ID of the content type to associate with the custom action.
• ShowInReadOnlyContentTypes – (optional) TRUE to specify that the action should only appear in the Manage Content Type screen, for Read Only Content Types. The default value is FALSE.
• ShowInSealedContentTypes – (optional) TRUE to specify that the action should only appear in the Manage Content Type screen, for Sealed Content Types. The default value is FALSE.
• ControlAssembly – (optional) Specifies the fully qualified name of the assembly of the control that supports the custom action. This attribute is used in conjunction with the next one.
• ControlClass – (optional) Specifies the name of the class of the control that supports the custom action. This attribute is used in conjunction with the previous one.
• ControlSrc – (optional)
• RegistrationType – (optional) Used to specify the type of attachment in per-item custom actions. The possible values are:
  • ContentType
  • FileType
  • List
  • ProgId
• RegistrationId – (optional) Depending on the RegistrationType value, this attribute can hold a Content Type ID, a File Type identifier, a List ID or a Program identifier.

The <UrlAction> Element

The <UrlAction> element is used inside the <CustomAction> element to specify what happens when the user clicks the link (or toolbar button, or menu item). It has a single attribute, Url, which is the address of the page to redirect the user to.

In this URL address you can use a few tokens that SharePoint will replace by the correct values when the user clicks it:

• ~site – relative address of the current web site.
• ~sitecollection – relative address of the root web site of the current site collection.
• {ItemId} – ID (Integer value) of the item being acted upon (if applicable).
• {ItemUrl} – URL of the item being acted upon (only works in document libraries).
• {ListId} – GUID of the list.
• {SiteUrl} – absolute URL of the current web site.
• {RecurrenceId} – Recurrence index (not supported in the context menu of list items).

The <HideCustomAction> Element

The <HideCustomAction> element is used to hide an existing custom action.

The following attributes can be used with this element:

• Id – (optional) Specifies the ID of this hide custom action element.
• GroupId – (optional) Identifies an action group that contains the action.
• Location – (required) Specifies the location of the custom action to hide. Check the possible values in the table below.
• HideActionId – (required) Specifies the ID of the action to hide.

Locations and Group IDs

The location and group ID values identify a specific place where the custom action must be created (or hidden). See below the possible combinations for both attributes.

Action Rights

Each custom action has its own set of permission requirements which are defined using the Rights attribute of the <CustomAction> element. The list below summarizes the possible values for this attribute.

• AddAndCustomizePages – Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services–compatible editor.
• AddDelPrivateWebParts – Add or remove personal Web Parts on a Web Part Page.
• AddListItems – Add items to lists, add documents to document libraries, and add Web discussion comments.
• ApplyStyleSheets – Apply a style sheet (.css file) to the Web site.
• ApplyThemeAndBorder – Apply a theme or borders to the entire Web site.
• ApproveItems – Approve a minor version of a list item or document.
• BrowseDirectories – Enumerate files and folders in a Web site using Microsoft Office SharePoint Designer 2007 and WebDAV interfaces.
• BrowseUserInfo – View information about users of the Web site.
• CancelCheckout – Discard or check in a document which is checked out to another user.
• CreateAlerts – Create e-mail alerts.
• CreateGroups – Create a group of users that can be used anywhere within the site collection.
• CreateSSCSite – Create a Web site using Self-Service Site Creation.
• DeleteListItems – Delete items from a list, documents from a document library, and Web discussion comments in documents.
• DeleteVersions – Delete past versions of a list item or document.
• EditListItems – Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries.
• EditMyUserInfo – Allows a user to change his or her user information, such as adding a picture.
• EmptyMask – Has no permissions on the Web site. Not available through the user interface.
• EnumeratePermissions – Enumerate permissions on the Web site, list, folder, document, or list item.
• FullMask – Has all permissions on the Web site. Not available through the user interface.
• ManageAlerts – Manage alerts for all users of the Web site.
• ManageLists – Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
• ManagePermissions – Create and change permission levels on the Web site and assign permissions to users and groups.
• ManagePersonalViews – Create, change, and delete personal views of lists.
• ManageSubwebs – Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
• ManageWeb – Grant the ability to perform all administration tasks for the Web site as well as manage content. Activate, deactivate, or edit properties of Web site scoped Features through the object model or through the user interface (UI). When granted on the root Web site of a site collection, activate, deactivate, or edit properties of site collection scoped Features through the object model. To browse to the Site Collection Features page and activate or deactivate site collection scoped Features through the UI, you must be a site collection administrator.
• Open – Allow users to open a Web site, list, or folder to access items inside that container.
• OpenItems – View the source of documents with server-side file handlers.
• UpdatePersonalWebParts – Update Web Parts to display personalized information.
• UseClientIntegration – Use features that launch client applications; otherwise, users must work on documents locally and upload changes.
• UseRemoteAPIs – Use SOAP, WebDAV, or Microsoft Office SharePoint Designer 2007 interfaces to access the Web site.
• ViewFormPages – View forms, views, and application pages, and enumerate lists.
• ViewListItems – View items in lists, documents in document libraries, and view Web discussion comments.
• ViewPages – View pages in a Web site.
• ViewUsageData – View reports on Web site usage.
• ViewVersions – View past versions of a list item or document.

The post SharePoint 2007 Deployment: Custom Action Features appeared first on Blog IT.