SharePoint 2007 is far more feature packed than SharePoint 2003, which is what Microsoft wanted to make sure of. They have also made SharePoint 2007 even more extendable that 2003. This means that not only can you immediately take advantage of the existing base of features, but you can also develop your own features. For example, any WebPart that can be activated is considered a feature. Any point of functionality that makes SharePoint more useful, like base column types, is a feature. And any piece of functionality that you can create in SharePoint that can be used by SharePoint or other users is called a feature. So when you really look at it, Microsoft picked a pretty good name … which is what confused me at first because a feature is just what it sounds like… and I did not expect that.

Part one of this article has a very specific purpose, to help explain one way to construct and deploy features. As such, the topics covered will include starting the solution with Visual Studio, laying out the initial contents, the construction of the initial contents, and how to deploy a shell of a feature with little actual functionality. The purpose for this is to clearly draw lines between the construction of a simple, deployable feature, and then how to build upon that simple feature with far more complex structures. This part will not cover building and populating lists, complex code or more. This first article will build up to explaining, preparing and deploying an empty feature so you can see where this process leaves off and the more complex tasks of making useful things happen begins. These more complex topics will be in the next part. With that, let us get started.

Now that we have the basic concept of a feature, let us build and deploy one that can be activated. You probably know by now that the base directory for SharePoint is C:\Program Files\Common Files\Microsoft Shared\web server extensions\12 on a standard SharePoint install. There are various names for this directory, and to make it easy for this article we will call it “12.” I use a small batch file in my path called “12.cmd” that has the following line: “@call start explorer "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12"” (without the outside quotes). This makes it very simple to type Start | Run | 12 | <Enter> to get into the 12 directory. As you look around at various directories and files you may notice that SharePoint is nothing if not open to use as a guide. Although I am sure you have also noticed that I did not say easy. None the less, it is there, and you will find as you progress in your learning that SharePoint development may not be especially well documented in all cases. Especially early in your development learning curve, I highly recommend that you locate an existing component that Microsoft has already constructed, and plagiarize it for your needs.

As you already know, deploying a feature is almost always required to get your code out to the SharePoint site and useful to the user. It is quite true that you can place certain files in a SharePoint environment and make them work, but in order to influence very powerful functionality, the act of deploying a feature is usually required.

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.

Next we want to add the components used to deploy the feature. This is fairly simple considering you simply perform various copy processes. If you open and review the Install.cmd file, you will see it probably looks very much like many other post-build deploy processes you have probably configured in the course of ASP.NET development. In fact, if you are beginning to think that SharePoint is decidedly ASP.NET-development-like, you would be correct. Although SharePoint is a decidedly advanced development platform, after you get past various new oddities of learning, you will find that any previous ASP.NET development work you have done will probably be used more than you may have guessed.

The first part of the Install.cmd file sets various obvious parameters. Next comes some gacutil and xcopy commands where you will see that your previous work in setting up a file structure is quite helpful. Only toward the end of this command file does it begin to deviate from any other ASP.NET project by running the STSADM tool to perform the SharePoint install process.

Note, if you want to run this command file each time you compile, simply place the following two lines, on separate lines, in the Post-build event command line box in the solution settings: “cd $(ProjectDir)” and “install.cmd.” On the other hand, if you compile a lot you may not want this running each time, in which case simply opening the command prompt and typing “cd /d C:\Code\SharePoint\Features\DeployHelloWorld” followed by running the command file will do the trick.

And at this point you may hear a mental click as you see how the feature.xml file is "run," which points to the newly GAC'd assembly and its primary class, which has a FeatureActivated method that begins the programmatic act of following your commands. Once this file has been run with the STADM component you should be able to activate your new feature. Open the site, Site Settings, Site Features and if all went well, somewhere in your list should be your new feature. Take a moment to activate and deactivate it and enjoy the knowledge that you now have the framework for your feature. Of course it does not do much at this time, but let us review.

1.    Declarative Functionality – Back in the feature.xml file you have the ability to reference a file called elements.xml. This file allows you to declaratively create lists, build fields and attributes, populate the lists with text data or point to data files to load into lists, build custom menu items and much more. The declarative functionality of this file (or files if you add and reference more element files) is quite extensive. In some ways this functionality is similar to running an SQL script file that builds the tables, fields, attributes and populates the data. Part two of this article will cover many examples.

2.    Programmatic Functionality – The next part of this article will also cover how the ReceiverAssembly and ReceiverClass objects call .NET code to respond to events using the FeatureActivated, FeatureDeactivating, FeatureInstalled and FeatureUninstalling methods. These methods, along with their associated properties, become a gateway between your code and SharePoint.

3.    ASP.NET – As you have probably already learned, SharePoint is based on ASP.NET, and as such the whole array of ASP.NET functionality is at your disposal. In the process of building a SharePoint feature you can include not only assemblies, but ASPX and ASCX objects, in addition to exposing canned and custom functionality via ASMX and WCF.

[Download Source]

The goal of this article has been to explain the definition of a feature, its make-up, and deployment. We deliberately did not deploy anything more than an empty shell yet, to make it obvious where the described actions leave off and the development and functionality of a useful feature begin. In the next article we will cover some of the Declarative Functionality, Programmatic Functionality and ASP.NET / .NET interoperability by way of other deployed components.

I would like to thank Microsoft for the development of such a wide and robust development environment, and Ted Pattison, John Holliday and The Ted Pattison Group for the work they have done in bringing to light so much of the SharePoint platform by way of publications and courses.