Before we begin coding let us review a few points that will help you better understand features, and as such will help you build this feature. If you open the 12 directory and look around, you will find that there is a directory called TEMPLATE. As you begin your solution you will see that we are building this solution as though it sat inside the 12 directory. One best practice that has been developed over time is to develop as though you were inside this directory. This has many positive effects that will become more apparent as we continue. Based on this consideration, the TEMPLATE directory has a place in our solution. If you dig deeper into the TEMPLATE directory you will see numerous other directories that will likely take on more meaning as you mentally correlate what you see with various objects that you have worked with in SharePoint over time, such as numerous ASPX pages, ASCX controls, multiple object templates, and so on. This location is very much the center of your development world in SharePoint

There is a lot of good news here and you have probably already picked up on it as well. No matter what you want to do, there is probably a good example here. And if you have loaded MOSS (as opposed to just WSS) then there are even more examples to be had. As in other realms of development, reusing code will help you a lot, and SharePoint has no lack of source code to learn from. This is the main reason that you will be recreating the 12\TEMPLATE structure in your solution. The idea is that when you deploy, your objects will easily slip in to place, in addition to the fact that during development you can readily tell where your code will go and how it will fit into the big picture.

With that, let us get started coding the solution while we wrap the deployment process around it. Feel free to change any of the following steps as you need, but when you can it is suggested to stay in line with what you see to minimize troubleshooting if something goes wrong.

1.    Make a directory at C:\Code\SharePoint\Features.

2.    Open Visual Studio 2008.

3.    Begin a C#, Windows, Class Library project. Contrary to what you may have thought, not all SharePoint development is conducted using ASPX or ASCX objects. You will likely develop many objects that perform functions based exclusively on the SharePoint API.

4.    Ensure the location of your new project is at C:\Code\SharePoint\Features.

5.    Enter a name, for example, “DeployHelloWorld.”

6.    Add a reference to the Microsoft.SharePoint.dll assembly, which can be found at “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI\Microsoft.SharePoint.dll” if you performed a standard installation.

7.    Delete the existing Class1.cs file. We will add other class files soon.

8.    Because the generated assembly will be placed in the GAC, use the solution properties pages signing tab to strongly sign the solution.

The feature.xml file

At this point we now have the basis for the solution we want. Next we will add the feature.xml. This is a manifest file that contains various attributes for the feature solution written in CAML (Collaborative Application Markup Language). The feature.xml is probably the most important file you will need for this process. It is literally the glue of the project. Not only will you define various attributes of your feature here, you will also point to other objects that are responsible for building still other objects, running code and so on.

In this example we are going to build a very basic feature definition that we will then “run,” which will install your feature. As stated above, the feature.xml file can call other declarative files and programmatic code to perform your needs. In this case we will not do this until part two. This is what will give us the ability to study and build an empty feature, yet still understand where to add in to this feature to connect more powerful functionality.

Let us go over the makeup of the feature.xml. Open the feature.xml in the example source.

1.    Feature ID – This is the GUID of the feature, which of course should be unique. If you use various GUID generators, for example the tool that comes with Visual Studio 2008, remember to drop any surrounding braces.

2.    Title, description and versions should be self explanatory.

3.    Scope – This refers to the context for which a feature can be activated at the following levels, for example, Web, Site, WebApplication and Farm.

4.    Hidden - Refers to the ability of users to see the feature inside the website. Once published, if Hidden is true then the feature is not available from any admin form in SharePoint, rather it must be enabled from code or the command line. Security through obscurity has its advantages, but more importantly a feature may not have context outside supporting other functions, and therefore, is only available via other objects.

5.    ImageURL – this image will be seen next to the name of this feature on the page used to enable this feature. Note that it uses the TEMPLATE\IMAGES directory as its base. As such you can use existing images but for example purposes I’ve copied an existing image to the local structure in the solution

6.    ReceiverAssembly – This is the name of an assembly that this feature will use. When a feature is loaded it can perform various actions based on the logic you have included. The construction and use of the ReceiverAssembly will be covered in greater detail farther along.

7.    ReceiverClass – This is the name of the class to be used in the ReceiverAssembly.

There are other objects that can be used in the feature.xml file, but for the sake of simplicity I have kept it to a minimum. I suggest using an advanced text editing program to review multiple examples of the feature.xml file, looking for examples of files that do and do not contain the above mentioned keywords.