Chapter 3: SharePoint Developer Tools in Microsoft Visual Studio 2010 (Inside SharePoint 2010)

Summary: Learn what's new with the SharePoint developer platform from experts on Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010. Read a preview of Chapter 3, SharePoint Developer Tools in Microsoft Visual Studio 2010, from Inside Microsoft SharePoint 2010.

Applies to: Business Connectivity Services | SharePoint Foundation 2010 | SharePoint Server 2010 | Visual Studio

This article is a preview excerpt from Inside Microsoft SharePoint 2010 by Ted Pattison, Andrew Connell, and Scot Hillier (ISBN 9780735627468, published with the authorization of Microsoft Corporation by O'Reilly Media, Inc. Copyright © 2010 by Critical Path Training, LLC). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Contents

• SharePoint Developer Tools in Microsoft Visual Studio 2010

• Life Before SharePoint Developer Tools

• Getting Started with the SharePoint Developer Tools

  • Using SharePoint Explorer

  • Adding a Feature Receiver

• Adding a SharePoint Project Item

• Deployment and Testing

• Working with Mapped Folders

• Conclusion

• Additional Resources

• About the Authors

SharePoint Developer Tools in Microsoft Visual Studio 2010

The release of SharePoint 2007 was a significant milestone for SharePoint as a development platform because in this version, Microsoft introduced support for features and solution packages. Soon after SharePoint 2007 released, however, it became clear within Microsoft and throughout the industry that more and better developer productivity tools were needed.

The SharePoint 2010 developer platform increases developer productivity by introducing the SharePoint Developer Tools in Visual Studio 2010. These new tools make developing for SharePoint 2010 much faster and easier because they automate grungy tasks and hide many of the low-level details that developers have to worry about when developing for SharePoint 2007.

For example, a project created using the SharePoint Developer Tools in Visual Studio 2010 is a special type of project, known as a SharePoint project. Every SharePoint project is created with built-in support to generate its output as a solution package. The SharePoint Developer Tools also integrate commands into the Visual Studio 2010 environment that make it easy to deploy and retract the solution package for a SharePoint project during testing and debugging.

Life Before SharePoint Developer Tools

The development tools available for SharePoint 2007 are quite primitive. What has made things worse is that everybody does development differently. If you asked five different SharePoint 2007 developers which tools they use, you would likely hear five different responses.

Visual Studio 2008 shipped with a toolset named Visual Studio Tools for Office (VSTO), which included two project templates for developing SharePoint 2007 workflow templates. However, these templates include no support for building a project into a .wsp file, which makes it challenging to distribute a development effort using best-practice techniques.

In a separate effort, the SharePoint team led a project to create a Visual Studio add-in named Visual Studio Extensions for Windows SharePoint Services 3.0 (VSeWSS). One of the primary design goals of the VSeWSS project was to build support into a Visual Studio project to generate a .wsp file behind the scenes. The VSeWSS add-in also adds integrated commands into Visual Studio to deploy and test the project using the generated .wsp file.

VSeWSS has experienced several problems throughout the SharePoint 2007 lifecycle. The 1.0 release of VSeWSS had some significant design flaws, so the adoption rate among intermediate to advanced SharePoint developers was low. Since the initial release of VSeWSS, the SharePoint team has shipped several updates to this toolset that have improved its usability and increased its adoption rate. Despite the updates, however, VSeWSS still has several noteworthy shortcomings.

First, the VSeWSS project format is hard-coded to a specific version of Visual Studio and a specific version of the VSeWSS add-in. That means you can't open a VSeWSS project unless you've installed the correct version of Visual Studio and the correct version of the VSeWSS add-in. Second, VSeWSS doesn't support team development environments that rely on the Microsoft Build Engine (MSBuild) or build servers that don't have Visual Studio installed. Finally, VSeWSS wasn't designed with extensibility in mind. That means using VSeWSS when developing SharePoint 2007 components that aren't directly supported by the toolset, such as workflow templates, is challenging and usually impractical.

Given the lack of effective developer tools for SharePoint 2007 available from Microsoft, many developers within the SharePoint developer community worked to fill in the gaps. They created their own tools and utilities to make SharePoint 2007 development easier. Many of the developers who created these utilities and tools posted their projects to CodePlex to share their efforts with other SharePoint developers around the world. Today, there are hundreds of SharePoint 2007 development projects on CodePlex.

The SharePoint 2007 project from CodePlex that has experienced the highest adoption rate among professional developers is WSPBuilder. The WSPBuilder utility allows developers to build SharePoint 2007 components using standard Visual Studio class library projects. WSPBuilder adds support to automate building the project into a .wsp file for best-practice deployment. Because WSPBuilder uses standard library projects, it is much more flexible thanVSeWSS, allowing you to move between different versions of Visual Studio and to automate the solution package build process using MSBuild.

Many developers and companies decided to go it alone and to add custom support to their Visual Studio projects to build them into .wsp files and deploy them for testing. This approach typically involves creating standard class library projects and adding batch files or custom tasks to integrate commands to call command-line utilities such as makecab.exe and stsadm.exe. Unfortunately, this individualistic approach leads to a development style in which the developer is responsible for tracking tedious details, a chore that has a significantly negative impact on productivity.

In summary, the developer tools available in SharePoint 2007 are immature, and are used inconsistently and with varying techniques across the developer community. One result is that beginning developers who are looking for guidance on the right way to get started have a difficult time finding it. Another consequence is that experienced .NET developers who have been using Visual Studio to build ASP.NET applications are frustrated because moving to the SharePoint 2007 development platform seems like a giant step backward in terms of productivity. Fortunately, the SharePoint Developer Tools put an end to these pains for both novice and experienced developers.

Getting Started with the SharePoint Developer Tools

The SharePoint Developer Tools are great for new developers just getting started with the SharePoint development platform because they abstract away many of the low-level details, such as creating the manifest.xml file and building a project into a .wsp file. Intermediate and advanced developers who already have experience with SharePoint 2007 development are going to appreciate the SharePoint Developer Tools because they support a high degree of extensibility.

You should understand that you can't use the SharePoint Developer Tools to develop solutions for SharePoint 2007. The SharePoint Developer Tools can be used only to develop for SharePoint 2010 and future versions. If you're still required to build business solutions for SharePoint 2007, you must use one of the older tools, such as VSeWSS or WSPBuilder, discussed in the previous section.

We begin our exploration of the SharePoint Developer Tools by examining a utility named SharePoint Explorer. This utility provides a convenient way to inspect a SharePoint site from within Visual Studio 2010 and to see the elements inside the site, such as lists and document libraries. After a quick discussion of SharePoint Explorer, we move ahead to the central topic of the chapter, building SharePoint projects using the SharePoint Developer Tools.

Before you begin using the SharePoint Developer Tools, you must ensure that your developer workstation is configured correctly. In particular, you must build out your development workstation as a single-server farm running either SharePoint Foundation or SharePoint Server 2010. A key point is that the SharePoint Developer Tools don't work correctly on a workstation that doesn't have a version of SharePoint 2010 installed. That's because the SharePoint Developer Tools were designed to run on a computer that is acting as a front-end Web server within a SharePoint 2010 farm.

Using SharePoint Explorer

As we just mentioned, the SharePoint Developer Tools include a utility named SharePoint Explorer. SharePoint Explorer is a visual component that runs inside the Server Explorer window of Visual Studio 2010, as shown in Figure 3-1. You work with SharePoint Explorer by adding SharePoint connections. To create a new SharePoint connection, you must provide a URL to a site running in the local SharePoint farm. Once created, a SharePoint connection displays a hierarchy of nodes that allow you to inspect the target site and the elements inside, such as its lists and document libraries. When you click the node for a site or a list, the standard Visual Studio property sheet shows the properties associated with the SharePoint object.

Figure 3-1 SharePoint Explorer allows you to inspect sites running within the local SharePoint site.

SharePoint Explorer doesn't provide any built-in functionality to modify a SharePoint site or to create new site elements such as a list instance. Therefore, you should think of a SharePoint connection as a read-only view into a SharePoint site. You primarily use SharePoint Explorer to inspect the properties and elements of a site using the standard Visual Studio property sheet.

SharePoint Explorer can also assist you with navigating to a site inside a browser window for testing purposes. For example, right-clicking on the node for a list lets you see a contextual menu command with the caption View in Browser. You can execute this command to launch a new session of Internet Explorer and navigate to the default view for that list.

SharePoint Explorer is fairly simple to understand and use. What makes it powerful is that it was designed to be extensible. Developers can create custom node types that load into a SharePoint connection along with the standard node types. This capability opens up the possibilities of custom node types that do more than just inspect sites. You could write a custom extension for SharePoint Explorer to modify the target site, or to add new site elements such as list instances or Web Parts.

Creating a SharePoint Project

Now it's time to create our first SharePoint project using the SharePoint Developer Tools. This walkthrough demonstrates what's required to create a new SharePoint project that contains a feature, a few elements, and a Feature Receiver. You'll also see how to test and debug your project inside a target test site running in the local farm.

The SharePoint Developer Tools provide several different templates for creating new SharePoint projects that are available in Visual Basic and C#. For example, you can see the project templates available for C# projects in the New Project dialog within Visual Studio 2010, by navigating to Visual C#\SharePoint\2010, as shown in Figure 3-2.

Figure 3-2 The SharePoint Developer Tools provide project templates for creating SharePoint projects.

When you select one of these project templates in the New Project dialog and then click the OK button to create a new SharePoint project, the SharePoint Developer Tools launch the SharePoint Customization Wizard shown in Figure 3-3. The SharePoint Customization Wizard prompts you for two pieces of information: the URL to a local site, and a trust level.

Figure 3-3 The SharePoint Customization Wizard prompts you for a URL to a test site and a trust level.

When you enter the URL in the SharePoint Customization Wizard, you must provide the URL to a site that is accessible within the local SharePoint farm. The SharePoint Developer Tools use this site URL when testing and debugging the project.

The SharePoint Configuration Wizard also makes you choose between two options: Deploy as a sandboxed solution or Deploy as a farm solution. Your choice mainly affects how the SharePoint Developer Tools deploy the project's solution package during testing and debugging. In this chapter, we'll work with projects that are deployed as farm solutions. In Chapter 4, we'll discuss how to develop projects that will be deployed as sandboxed solutions.

We first create a new SharePoint project named WingtipDevProject2 using the Empty SharePoint Project template and a site URL of http://intranet.wingtip.com. We also elect to create the new project using the option to deploy it as a farm solution. When you click the Finish button in the SharePoint Customization Wizard, Visual Studio takes a few seconds to create and configure the new project. Figure 3-4 shows what the new SharePoint project looks like in Solution Explorer.

Figure 3-4 Every SharePoint project is created with a Features node and a Package node.

All Visual Studio projects contain standard nodes such as Properties and References. SharePoint projects have two additional nodes that exist only within SharePoint projects: the Features node and the Package node.

You use the Features node to add new features to a SharePoint project. Notice that the Features node is empty when you create a new SharePoint project using the Empty SharePoint Project template. You use the Package node to track project-wide settings related to building the project into a solution package .wsp file.

All SharePoint projects also have three special menu commands: Deploy, Package, and Retract. These menu commands, exclusive to SharePoint projects, are available when you right-click the top-level project node in Solution Explorer. These three menu commands are shown in Figure 3-4.

You can run the Package command to build a SharePoint project into a solution package. You can use the Deploy command to run a sequence of deployment steps that deploy the solution package in the local farm so that you can test and debug your work. The Retract command reverses the act of deployment by retracting the solution package from the local farm.

Creating a Feature

To add a new feature to a project, right-click the Features node and click the Add command. The SharePoint Developer Tools respond by creating a new feature with a generic name such as Feature1. You should get in the habit of renaming features with a meaningful name right after you create them. You can rename a new feature by right-clicking on the feature's toplevel node and clicking the Rename command. In our example, we create a new feature and rename it ProductDevelopment, as shown in Figure 3-5.

Figure 3-5 The SharePoint Developer Tools allow you to add new features to the Features node and to configure features using the Feature Designer and the standard Visual Studio property sheet.

Once you've created and renamed a new feature, you can double-click its node inside Solution Explorer to open it inside the Feature Designer, which is shown on the left-hand side of Figure 3-5. The Feature Designer allows you to modify the three feature properties, Title, Description, and Scope. Remember that a Scope setting of Web means that the feature activates at the site level and a Scope setting of Site means that the feature activates at the site collection level. The feature in our example has the Title of Wingtip Product Development and a Scope of Web.

Many other feature properties can be viewed and modified through the feature's property sheet, which is shown in the lower right-hand section of Figure 3-5. For example, you can use a feature's property sheet to assign a value to the Version property. When you're just getting started, getting to the property sheet for a feature can be a little tricky. The secret is to open the Feature Designer and then click it so that it becomes the active window. Once you make the Feature Designer the active window, Visual Studio shows the property sheet and allows you to view and update many additional feature properties.

Adding a Feature Receiver

Now it's time to create a Feature Receiver so that we can add some C# code that will execute whenever our new feature is activated or deactivated. The SharePoint Developer Tools make adding an event receiver to a feature easy. Just right-click the feature's top-level node and click the Add Event Receiver command, as shown in Figure 3-6.

Figure 3-6 The SharePoint Developer Tools make it easy to extend a feature by adding a Feature Receiver.

When you add an event receiver using this technique, the SharePoint Developer Tools do quite a bit of work for you behind the scenes. First, they add a source file, which is based on either C# or Visual Basic, depending on the language of the underlying project. If you create a Feature Receiver for the feature named ProductDevelopment, the SharePoint Developer Tools create a C# source file named ProductDevelopment.EventReceiver.cs. The SharePoint Developer Tools also add configuration data behind the scenes. This configuration data results in the building of a feature.xml file that properly configures the ReceiverClass and ReceiverAssembly attributes so that SharePoint Foundation recognizes the Feature Receiver, and the event handlers added to the Feature Receiver are executed at the correct times.

When you first open a source file created for a Feature Receiver, such as ProductDevelopment.EventReceiver.cs, you see that the SharePoint Developer Tools have added a class definition for the Feature Receiver with method stubs that are commented out. You simply uncomment the stubs, which represent the events you want to handle, and add your custom code. In this walkthrough, we're going to add code for the FeatureActivated and FeatureDeactivating methods, so that we can run custom C# code on the front-end Web server whenever the feature is activated or deactivated. In Listing 3-1, we include only the stubs of these two event handler methods and leave the implementation up to your imagination.

Listing 3-1 The SharePoint Developer Tools automatically generate the starting code for an event receiver class.

using System;
using System.Runtime.InteropServices;
using System.Security.Permissions;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Security;

namespace WingtipDevProject2.Features.ProductDevelopment {

  [Guid("b53e6391-97b6-4ae9-a1b9-579d14bd4404")]
  public class ProductDevelopmentEventReceiver : SPFeatureReceiver {

    public override void FeatureActivated(SPFeatureReceiverProperties properties) {
      // your activation code goes here
    }

    public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {
      // your deactivation code goes here
    }

  }
}

The SharePoint Developer Tools also add a special GUID attribute when creating a new Feature Receiver class to give it a unique identifier. You shouldn't remove the GUID attribute from a feature class because the SharePoint Developer Tools use the GUID behind the scenes during the packaging process.

Adding a SharePoint Project Item

The primary way you extend the functionality in a SharePoint project is by adding new items created from special project item templates provided by the SharePoint Developer Tools. These items are known as SharePoint project items. You can see these templates inside the Add New Item dialog at C#\SharePoint\2010, as shown in Figure 3-7.

Figure 3-7 The Add New Item dialog supplies a folder of templates for creating SharePoint project items.

In our walkthrough, we'll create a new list instance named Scientists. When we choose the List Instance template and then click Add to create a new project item instance, SharePoint Developer Tools display the SharePoint Customization Wizard dialog to prompt us for the various properties of the new list. You can see in Figure 3-8 that we've given the list a display name of Scientists and indicated that we want the new list instance created from the Contacts list type.

Figure 3-8 The SharePoint Customization Wizard prompts for values to initialize the new List Instance project item.

When you click the Finish button in the SharePoint Customization Wizard, the SharePoint Developer Tools create a top-level folder in the project with the same name as the project item instance. Inside this folder is an elements.xml file with a ListInstance element, as shown in Figure 3-9. In some cases, the XML that the SharePoint Developer Tools provides is sufficient for your needs. In other cases, you might be required to hand-edit the XML to change an attribute value or to add new attributes or elements.

Figure 3-9 A ListInstance project item includes an elements.xml file and the Deployment Conflict Resolution property.

You can select the top-level folder for a project item to see its properties in the standard Visual Studio property sheet. Note that the project item itself can have its own properties. Also note that List Instance project items have a property named Deployment Conflict Resolution that allows you to configure the project item's behavior when the project is deployed during testing.

The Deployment Conflict Resolution property was designed to remedy an underlying problem. Although a ListInstance element can be used to create a new list during feature activation, it doesn't automatically delete the list during feature deactivation. Therefore, you can run into problems during testing when you're continually activating and deactivating a feature.

What happens if you activate a feature and then deactivate it? The feature creates a new list and leaves it in the site after it is deactivated. The next time you activate the feature, you'll run into a problem. The feature can't create the new list because another list of the same name already exists. In SharePoint 2010, this attempt to create the list instance results in a silent failure. The feature still activates successfully, but the new list isn't created.

The main idea behind the Deployment Conflict Resolution property is that you can configure a project item to delete any elements in the target site that might impact your testing. For example, when you deploy the project, the SharePoint Developer Tools can be configured to automatically look for and delete any list named Scientists. As long as the SharePoint Developer Tools delete the existing list instance prior to feature activation, you'll be able to properly test what happens when the list instances get created during activation.

A List Instance project item has a Deployment Conflict Resolution property value, which by default is set to a value of Prompt. Whenever you deploy the project and the SharePoint Developer Tools detect a conflict with an existing list in the test site, you'll be prompted to specify whether or not you want to delete the list. You can suppress the prompting behavior by changing the property value for Deployment Conflict Resolution to Automatic.

At this point, we've created a new feature that has both a Feature Receiver and an element manifest. However, we haven't yet dealt directly with the feature.xml file. This file is one of key productivity points of the SharePoint Developer Tools. The SharePoint Developer Tools deal with the details of the feature.xml file behind the scenes. Beginners don't even have to know about the feature.xml file. However, you can get direct access to feature.xml, which might be required in some advanced scenarios.

Let's examine Figure 3-10 so that you can see what the Feature Designer looks like after you've added a project item. Notice that the Feature Designer shows the project item named Scientists inside its collection of items. Behind the scenes, the SharePoint Developer Tools have automatically updated the feature.xml file by adding a reference to the element manifest from the Scientists project item.

Figure 3-10 The Feature Designer allows you to add project items into a feature—or remove them.

The Feature Designer allows you to add and remove project items. For example, imagine the scenario in which you've added a second feature to this project. You could remove the project item from this feature and then add it to the first feature you created. The SharePoint Developer Tools even allow you to add the same project item to two features at the same time (in rare scenarios where that makes sense).

Deployment and Testing

Now that we have a SharePoint project with a feature, a Feature Receiver, and a project item, it's time to deploy and test our work. If you right-click the top-level project node inside Solution Explorer to drop down the context menu, you see a Deploy command and a Retract command. You'll use these commands constantly when you test and debug SharePoint projects.

You might be wondering what happens when you execute the Deploy command. The answer is, it depends. More specifically, it depends on which deployment configuration your project is using.

You can see and modify the available deployment configurations for a SharePoint project from the SharePoint tab of the Project Properties dialog, as shown in Figure 3-11. Every new SharePoint project is created with two deployment configurations, Default and No Activation. You can add more deployment configurations if you want something different. However, you can't modify Default and No Activation. You can only modify deployment configurations you've added.

Figure 3-11 The Project Properties dialog for a SharePoint project has a SharePoint tab showing deployment configurations.

Notice the two text boxes on the SharePoint tab: Pre-deployment Command Line and Post-deployment Command Line. Using these text boxes, you can add command-line instructions that will execute either just before or directly after the active deployment configuration is processed. For example, you can add a command-line instruction to call a custom Windows PowerShell script using the techniques you learned in Chapter 2 about integrating Windows PowerShell scripts into Visual Studio 2010.

The fact that you can change or modify the deployment configuration for a SharePoint project provides a convenient degree of flexibility. The SharePoint Developer Tools allow you to control the processing that occurs behind the Deploy and Retract commands by using units of execution known as deployment steps.

To see the deployment steps within a specific deployment configuration, select that deployment configuration in the SharePoint tab and then click the View button. Figure 3-12 shows the sequence of deployment steps for the default deployment configuration. First, the target Internet Information Services (IIS) application pool is recycled. Then any previous deployment of the solution package is retracted and removed. Next the latest build of the project's solution package is installed and deployed. Finally, any project features that have a Scope setting of either Web or Site are automatically activated.

Figure 3-12 Each deployment configuration is made up of deployment steps.

On the left-hand side of the View Deployment Configuration dialog shown in Figure 3-12, you can see a list of available deployment steps that come out of the box with the SharePoint Developer Tools. The one obvious deployment step that is missing is the one for updating a solution package so that you can test and debug your upgrade actions from within Visual Studio. So how then can you run a command from Visual Studio 2010 to perform a solution upgrade in your local farm?

One approach is to create a new deployment configuration that doesn't contain the deployment steps for Retract Solution or Add Solution. Then you could add a Postdeployment Command Line instruction call to a custom Windows PowerShell script that runs the Update-SPSolution cmdlet, as we did in Chapter 2.

Another approach is to either create or find a custom deployment step that adds the functionality you need. This option is possible because the team that created the SharePoint Developer Tools designed deployment steps to be extensible. A developer can create a custom extension for Visual Studio 2010 and the SharePoint Developer Tools that adds custom deployment steps. Within the SharePoint developer community, Visual Studio extensions that extend the SharePoint Developer Tools with a custom deployment step for updating solutions—and much more—are already available.

Working with Mapped Folders

You now know how to create features and project items using the SharePoint Developer Tools. As you've seen, the SharePoint Developer Tools do a pretty good job of hiding the details of where the files for a feature need to be deployed inside the SharePoint root directory. However, in certain scenarios, a developer is required to deploy a file into a specific location inside the SharePoint root directory. For this reason, the SharePoint Developer Tools include mapped folders.

Let's say you want to deploy a custom image file named FeatureIcon.gif that will appear alongside the Wingtip Product Development feature on the feature management page. Going through the steps to accomplish this will give you a chance to learn how the SharePoint Developer Tools use mapped folders. They key point is that mapped folders can be used to deploy custom files inside the SharePointRootFiles folder into standard SharePoint folders such as TEMPLATE, CONTROL TEMPLATES, LAYOUTS, and IMAGES.

We're going to use an example of deploying an image file inside the IMAGE directory, but you can also use mapped folders for deploying many other types of files, including CSS files, JavaScript files, XSLT files, and Silverlight XAP files.

The first step is to add a new mapped folder to the project that will deploy its files into the SharePoint IMAGES folder. Just right-click the top-level project node in Solution Explorer, expand the Add menu, and click the SharePoint "Images" Mapped Folder command. Once you've created the Images folder inside your project, you should be able to observe that the SharePoint Developer Tools automatically created a child folder with the same name as the current project. In our example, the SharePoint Developer Tools created an Images folder inside the project that contains a child folder named WingtipDevProject2, as shown in Figure 3-13. We can then add custom image files to this folder, such as FeatureIcon.gif and SiteIcon.gif, the ones shown in Figure 1-13. The easy way to add custom image files is to right-click the child folder named WingtipDevProject2 and then click Add\Existing Items. When the resulting dialog opens, you can navigate to the folder on your development workstation that contains a copy the files you want and copy them into your mapped folder.

Figure 3-13 You can use mapped folders to deploy custom files inside the RootFiles folder to standard folderssuch as TEMPLATE, LAYOUTS, and IMAGES.

This example demonstrates how the SharePoint Developer Tools help ensure that best practices are followed in SharePoint development. More specifically, when deploying image files within a farm solution, you shouldn't add your custom files directly inside the Images folder because doing so creates potential problems with file name conflicts. The best practice is to add images to a child directory inside the Images folder that is named after the solution package. In this example, the SharePoint Developer Tools automatically created a child folder named WingtipDevProject2.

The SharePoint Developer Tools do a good deal of work behind the scenes to keep track of all your source files and to figure out which ones need to be compiled inside the output solution package. To do this monitoring, the SharePoint Developer Tools add two extra properties to each source file inside a SharePoint project: Deployment Location and Deployment Type. In Figure 3-14, you can see how the values for these two properties are set for the FeatureIcon.gif file that has been deployed in a mapped folder.

Figure 3-14 The SharePoint Developer Tools track source files in a SharePoint project using two extra properties, Deployment Location and Deployment Type.

Now that we've taken the steps to deploy FeatureIcon.gif into the farm when the solution package is deployed, we should configure the Wingtip Product Development feature by modifying its ImageUrl property. Just open the feature in the Feature Designer so that you can access the feature's property sheet. Inside the property sheet, you can update the ImageUrl property with a URL relative to the Images folder, which in this case is WingtipDevProject2\FeatureIcon.gif.

Let's finish our discussion of the SharePoint Developer Tools by looking at the Package Designer. If you expand the Package node in a SharePoint project, you'll see an inner node named Package.package. If you double-click this node, the SharePoint Developer Tools display the Package Designer. At the bottom left-hand corner of the Package Designer are three tabs: Design, Advanced, and Manifest. These tabs allow you to switch back and forth between different views of the project's solution package. Figure 3-15 shows the Manifest view, which reveals the XML that is written into the manifest.xml file when the SharePoint Developer Tools build the project into a solution package.

Figure 3-15 The Manifest View of the Package Designer shows the XML that goes into the manifest.xml file.

In many scenarios, a developer doesn't need to inspect or care about the XML that goes into the manifest.xml file. After all, the SharePoint Developer Tools are valuable partly because they hide so many of the details developers had to worry about in SharePoint 2007 development.

In other scenarios, however, a developer will need to directly edit the manifest.xml file. For example, when you need to add an XML element that the SharePoint Developer Tools don't directly support, such as the ActivationDependencies element discussed in Chapter 2, you have to add it manually to manifest.xml.

If you look at the Package node in Solution Explorer in Figure 3-15, you'll notice a source file named Package.Template.xml. If you open this file, you'll see that it has a top-level Solution element but no inner elements. All you need to do is add the ActivationDependencies element to this file inside the Solution element. When the SharePoint Developer Tools generate the manifest.xml file, they merge the XML elements they create behind the scenes with any XML elements you have added to Package.Template.xml. By using this technique, you can call on your knowledge of SharePoint development to supplement what the SharePoint Developer Tools support directly.

In addition to making direct edits to a project's manifest.xml file, you can also make direct edits to the feature.xml file for any feature in a SharePoint project. You'll need to edit directly in feature.xml when you want to version a feature definition by adding an UpgradeActions element, because the SharePoint Developer Tools don't directly support adding any elements dealing with feature upgrade functionality.

Inside the node for each feature, you should be able to locate and open the template.xml file. Once you open template.xml for a feature, you can add elements inside the top-level feature element. For example, you can add an UpgradeActions element like the one shown in Chapter 2. The SharePoint Developer Tools merge the UpgradeActions element and all the inner child elements into the feature.xml file that is built in the project's solution package.

Conclusion

In this chapter, we took a closer look at the SharePoint Developer Tools in Visual Studio 2010. We'll continue to go over other techniques you can use in the SharePoint Developer Tools throughout the remaining chapters of this book. This chapter was mostly about the fundamentals of using this new toolset. Here's a summary of those fundamentals.

The SharePoint Development Tools provide Visual Studio project templates for creating SharePoint projects. Every SharePoint project has the ability to build itself into a solution package and to deploy this solution package for testing and debugging on a local farm. You mainly grow out the functionality of a SharePoint project by creating SharePoint project items. Each SharePoint project item has its own folder, set of files, and properties. Certain types of project items, such as list instances, provide conflict resolution to clean up the target test site during activation. For advanced developers who want to move beyond the basics, the SharePoint Developer Tools allow you to add mapped folders and to make direct edits to low-level files such as manifest.xml and feature.xml.

Additional Resources

For more information, see the following resources:

• Chapter 1: SharePoint 2010 Developer Roadmap (Inside SharePoint 2010)

• Chapter 2: SharePoint Foundation Development (Inside SharePoint 2010)

• Chapter 4: Sandboxed Solutions (Inside SharePoint 2010)

• SharePoint 2010

• SharePoint Server 2007

• SharePoint Developer Center

About the Authors

• Ted Pattison is an author, instructor, and co-founder of Critical Path Training, a company dedicated to education on SharePoint technologies. As a Microsoft SharePoint Most Valuable Professional (MVP), Ted frequently works with the Microsoft Developer Platform Evangelism group to research and author SharePoint training material for developers early in the product life cycle while in its alpha and beta stages. Ted also writes a developer-focused column for MSDN Magazine titled Office Space.

• MVP Andrew Connell is an author, instructor, and co-founder of Critical Path Training, a SharePoint education-focused company. Andrew is a six-time recipient of Microsoft’s Most Valuable Professional (MVP) award (2005-2010) for Microsoft Content Management Server (MCMS) and Microsoft SharePoint Server. He authored and contributed to numerous MCMS and SharePoint books over the years including his book Professional SharePoint 2007 Web Content Management Development by WROX. Andrew speaks about SharePoint development and WCM at conferences such as Tech-Ed, SharePoint Connections, VSLive, SharePoint Best Practice Conference, SharePoint Evolutions Conference, Office Developer Conference, and Microsoft SharePoint Conference in the United States, Australia, England, and Spain. Andrew blogs at Andrew Connell Blog and on Twitter @andrewconnell.

• Scot Hillier is an independent consultant and Microsoft SharePoint Most Valuable Professional (MVP) focused on creating solutions for Information Workers with SharePoint, Office, and related .NET Framework technologies. He is the author/coauthor of 15 books and DVDs on Microsoft technologies, including Inside Microsoft SharePoint 2010 and Professional Business Connectivity Services. Scot splits his time between consulting on SharePoint projects, speaking at SharePoint events like Tech-Ed, and delivering training for SharePoint developers. Scot is a former U.S. Navy submarine officer and graduate of the Virginia Military Institute. Scot can be reached at scot@shillier.com.