How to Copy Feature Elements in Visual Studio SharePoint Solutions

This is a continuation of the previous post, Save Site As Template + Import SharePoint Solution Package == Love.

Once you’ve extracted your field, content type, and list instance, you are ready to incorporate the element manifests and related resources into your main project. In this example I have a Web Part named HypotheticalPart and a solution named HypotheticalWebPart.

First I need to open the solution’s folder in Windows Explorer.

To review, the solution that contains my other features looks like this:

I open that solution’s folder in a second instance of Windows Explorer and copy the Content Types, Fields, and List instances folders to the clipboard.

And then paste them into the first Explorer window.


To complete the job, I go back to the HypotheticalWebPart solution in Visual Studio and click the Show All Files button in Solution Explorer.

This reveals the folders I copied previously. I simply click each of them and select Include In Project.


That’s it! The feature elements are now in my project and included in my feature.

Author: Doug Ware

Save Site As Template + Import SharePoint Solution Package == Love

Update! A series of posts about using this technique with publishing sites is available here: Using Save Site as Template with Publishing Sites – Introduction

Say you’re working on a new solution that requires certain elements like fields, content types, and list instances to provide data to a Web Part or some other custom functionality. In this post I’ll show you how to create features to provision all of those elements in only a few minutes.

Consider the list shown below. It’s based on the Links list and is bound to a content type named Fun Link. Note that this could just as easily be based on the Custom List template.

The site content type, Fun Link, contains a custom site column, Classification, that provides a set of choices.

Getting this into Visual Studio is easy. Open up the Site Settings page and click the Save site as template link.

Give your template a name. It doesn’t matter what name you choose because the template is just an intermediate step that you’ll throw away when you are done. If you choose Include Content, your new feature will recreate the list data.

When the operation completes, follow the links the your site’s Solution Gallery and save the resulting WSP to your local machine.

Next, open Visual Studio and create a new project. Select the Import SharePoint Solution Package template.

Next choose either Farm or Sandbox deployment. In this example, either works fine.

The SharePoint Customization Wizard displays. You don’t want everything in the wsp, just the items you need to recreate the custom list. Press CTRL+A to select all the items and then SPACE to deselect everything. Now you are ready to select only the items you need. In this case you need the Fun Link content type.

The Classification field…

The Fun Links list instance…

And the ListsFun Links_pages module.


Once you have the set of items you need selected, click Finish. Visual Studio will display the warning shown below telling you about all sorts of dependencies. You don’t need any of them because they are all fields from the core fields feature and are always available on every site. Click No and your done!

Here is a screen shot of the new solution in Solution Explorer.

At this point I probably need to include the features in my main solution. Read How to Copy Feature Elements in Visual Studio SharePoint Solutions to see how it’s done.

Author: Doug Ware

SharePoint 2010 End User Training Site

I’d like to thank the folks over at fpweb for providing the hosting for my newest SharePoint 2010 site

The site contains over ninety (90) short how-to articles that I wrote to help end users get up to speed on as authors of SharePoint 2010 wikis and publishing sites. I hope you find it useful!

If you would like a copy of the site’s pages as a sandbox solution that you can customize to train your own users, send me an email!

Here is a screen shot of the current version. I still have some branding work to do!

Author: Doug Ware

SharePoint 2010 Fixed Width Master Pages Revisited

This post is an update to this post about fixed width pages I wrote when SharePoint 2010 was still in beta. If you follow the instructions in that post you’ll get a fixed width page, but it will have an unnecessary (and ugly) vertical scroll bar in the page’s main content area. The problem is in a function in init.js, FixRibbonAndWorkspaceDimensions. You can read about the work this function does in this post about ribbon positioning. FixRibbonAndWorkspaceDimensions does exactly what it says, but if you change the vertical layout of your page or add a footer it will give you fits. It does math and changes the size and position of various div elements independently of your CSS!

Here are the basic steps I use to create a fixed width page in the released versions of SharePoint Foundation and SharePoint Server 2010. You will almost certainly need to do more than this based on your specific design, but this should get you started. Note, this un-floats the ribbon. If you want to achieve the dynamic positioning FixRibbonAndWorkspaceDimensions provides, you’ll need to recreate it with your own script against your own element identifiers.

Find the following <DIV>

<div id="s4-workspace">

Change the id attribute to something else like:

<div id="my-workspace">

Add the appropriate styles to your CSS as follows:

<style type="text/css">

    body.v4master { 






        margin-left: auto; 

        margin-right: auto; 

        width: 960px;




        background-color: white;




This is what it looks like on a stock Team site.

Author: Doug Ware

SharePoint REST (ODATA) is Insecure

SharePoint 2010 includes a number of new services to allow interoperability with other systems and to make it easy to create rich Internet applications. Among these is SharePoint’s ODATA implementation provided by the ListData.svc service. Overall, I think the REST is an awesome lightweight alternative to formal SOAP. Unfortunately, the implementation SharePoint provides opens a large attack surface that makes it very easy to discover the information for every user in a site.

Unlike alternative interoperability services like the traditional SOAP based services and the SharePoint Client Object Model, you must access the ListData.svc with an account that has Browse User Information permission. Consider a scenario where you want to allow a system external to your organization to read and write items in a site. You can create a permission level that allows this interaction by granting:

  • Add Items
  • Edit Items
  • Delete Items
  • View Items
  • Use Remote Interfaces
  • Open

An account with this set of permissions allows the use of the Client Object Model and some of the SOAP services to the external system to read and write list items and documents. However, the account can’t browse the site’s contents because it hasn’t got View Pages permission, nor can the account access information about the other accounts with access to the site.

SharePoint’s WCF Services implementation, ListData.svc, will not work with the above set of permissions. To make it work, you must grant Browse User Information permission.

There are probably many scenarios where you can justify this, but I personally think that a data interchange technology that reveals the accounts with access to the data store is best avoided considering that the alternatives don’t have this flaw.

I hope this is fixed soon, because I’d love to use REST with SharePoint and I will as soon as Microsoft makes it possible to harden SharePoint REST (OData) security. At the moment I think it would be irresponsible to do so in most of the scenarios where REST is attractive.

Author: Doug Ware

Why There is a Shortage of SharePoint Experts

This post started out as a short reply to a discussion on LinkedIn about this post: Why there is a shortage of SharePoint Experts. Once I hit the fourth paragraph I decided it made a better blog post then a comment. 🙂

There is a shortage of SharePoint experts because the learning curve for the base technologies is large and the learning curve for the breadth of SharePoint functionality is even larger.

Consider SharePoint 2010 Server Enterprise edition. You can deploy the platform as a public facing site with heavy customization and branding, as a team collaboration portal, as a business intelligence and information delivery, as a stand-alone or connected enterprise content management system, as a search appliance, as a business process automation (workflow) platform, and as a basis for custom applications. There are even more uses, but hopefully you get the basic idea – you can use it for lots of unrelated things.

To call yourself an expert, you should understand most or all of these core uses and the related tools used by end users, developers, and administrators. The SharePoint learning curve is honestly measured in years – assuming that you have a few years’ experience building either Windows applications or building and administering complex server systems.

Fortunately, most organizations do not need a full-time SharePoint expert to be successful. Most deployments involve a small subset of the functionality. Most people who work in a corporate setting will use a subset of the tools and fulfill a role in a larger team. If you are looking to implement SharePoint, my advice is to spend the money on a good consultant(s) who is an actual SharePoint expert to create a good foundation and focus on hiring or training full time staff to participate in the build-out and maintain the completed system. Once you are up and running, say goodbye for now to the experts and use them on an ongoing basis only as needed.

The multi-year learning curve plus the sharp upward demand curve means that the supply of experts will be well short of demand for several more years. The supply of people who have serious SharePoint experience will obviously increase along with adoption, but there is no reason you should expect someone who worked in a large heavily controlled collaboration environment where the focus was to maximize stability and minimize risk through aggressive governance to know much about building high-quality public facing sites with significant branding and customization (or vice-versa). That’s not to say the person could not make the switch, but it is to say that person is not an expert.

For those organizations looking to find a "SharePoint expert" on the cheap – don’t hold your breath. If you are offering a rate that is comparable to that earned by a qualified Web developer in your area, ask yourself why someone who is already a qualified to do work that pays the Web developer rate as a Web developer is willing to provide the additional value of their additional 3+ years of learning in the SharePoint domain at no additional cost to work on SharePoint. Instead try to hire to the narrower skill set you actually need.

The pool of people who have solid experience in one of WCM, ECM, BPA, BI, information architecture, system administration, etc. who can be very productive in a SharePoint environment with the right training and mentoring is large. Build your team from this pool. Trying to build a team of SharePoint experts is much harder and more expensive. More importantly, it’s probably an unnecessary and poor strategy.

Author: Doug Ware