Every developer shop I visit is focused on building better software more easily, typically by automating a big part of the development process. For SharePoint developers Visual Studio (VS) 2010 packs a big punch when it comes to doing exactly that. Not only does it provide a pretty seamless out-of-the-box experience, the project system for SharePoint is also fully extensible. Extensibility that is actually easy to do!
You can make it a one-step action to set up a medium-sized SharePoint project for a client fully configured with Web Parts, Pages and other content. Easily add more ways to deploy software locally on your test machine or into the remote test environment, or simply add a button that relieves you from a frequently repeating sequence of mouse clicks and edits.
You develop these extensions to the way you do your work (eh, life extensions?) using VS itself. First of all, you’ll need a class library to store your extension classes.
Next, you’ll need to create an installer for the extension. Instead of using Windows Installer, you build a VSIX container using the new VSIX project that is available after you install the VS SDK. VSIX uses strict file-based deployment, meaning no writing to the system registry or GAC.
The benefit of this is you get the ability to safely publish your extension to the online VS Gallery. This gallery is integrated into the Extension Manager which now sits on the Tools menu, which Figure 1 shows.
There are a few types of SharePoint project specific extensions that you can create. As you can expect, you can add new project item templates, including a “code-behind” implementing features such as adding context menus and adding refactoring support. You can see this type of behavior in the Visual Web Part project. When you rename or move the ASCX file, the code file is automatically updated to reflect this change.
Another target for extensibility is the SharePoint Explorer. You’ll find that in this area there is also little that you cannot add to. Using only a few lines of code, you can create new nodes to show content that’s not visible out of the box. Or again extend the existing nodes with actions.
One area that I find particularly interesting for moving the development process to the next scale is making deployment work better. When you hit F5, a configurable sequence of steps executes before attaching the debugger to the IIS Worker Process.
You can define multiple named sequences including the steps to execute. F5 then runs one of these named sequences (see Figure 2).
Why this is important is simple: development speed. When making a tiny change to your project, it’s painful to need to go through a full retract / deploy sequence, when updating a DLL and resetting IIS would do. Using custom deployment steps, you can add to the out-of-the-box model of doing a full retract / deploy and also support X-Copy, Upgrade, Copy DLL, and other approaches.
For the “but-how-does-that-work” crowd, here’s an interesting tidbit. You can quickly recognize that VS is connected to SharePoint and uses the object model to learn about current fields, content types, and all the other things the object model provides us access to. VS is a 32-bit application while SharePoint is 64-bit only. There is also a difference in the supported .NET Framework version: .NET Framework 4 versus .NET Framework 3.5. To allow VS to communicate with SharePoint, an intermediary exists in the form of a separate process called VSSPHOST4.exe. VS communicates with this host to get to SharePoint. For extension developers this means you will often have a third component that loads into this host.
Being a developer, I can’t just leave without showing at least a little bit of code. Here’s how to create an extension that adds a menu item to the context menu of the project in the Solution Explorer. Implement a single method to get going, and export the class so that VS can find it, and you’re done!
\\[Export(typeof(ProjectExtension)\\]
public class ProjectExtension
: ISharePointProjectExtension
\\{
public void Initialize(ISharePointProjectService projectService)
\\{
projectService.ProjectMenuItemsRequested +=
ProjectMenuItemsRequested;
\\}
void ProjectMenuItemsRequested(object sender,
SharePointProjectMenuItemsRequestedEventArgs e)
\\{
IMenuItem reset = e.ActionMenuItems.Add("Reset IIS");
reset.Click += delegate \\{ ... \\};
\\}
\\}
Wouter van Vugt is a development specialist in SharePoint and a trainer with Critical Path Training. To learn more about Wouter, click his name beside his photo.
