SharePoint Development Tools or Not?

I’m asked quite frequently about tools for SharePoint development. In my book, I wrote that I generally stay away from tools until I understand the underlying technology completely.

To clarify what that means, I thought I’d go into a bit more detail on my strategy for tools in SharePoint.

First of all, I never, ever start out installing a tool for a new task. Currently, I’m working on the next issue of USPJ which, after a massive comment storm, will be on SharePoint Workflows in Visual Studio. It is very tempting to just utilize the built-in support for SharePoint workflows in the latest Visual Studio version, however that would not teach me anything about how workflows work under the hood.

So, what happens when one reaches a problem? Well, in this particular case, I reached a point at which I was presented with a mission Workflow History list when I tried using the F5 method of testing a workflow. Since the tool was supposed to handle everything, I was stuck, short of creating the workflow history list manually.

It turns out that an easy fix was to re-run the workflow configuration wizard. However, this means that I now had to learn using the tool rather than learning how the technology works.

You may argue that this investment in learning the tool means I am more efficient next time. That is true, however, it also means that when the tool is not sufficient or does not work correctly, I will have far less knowledge about what is going on to work around any issues with the tool. As such, you are only more efficient when you are working with features that the tool supports, while everything else may slow down because you lack the knowledge about the underlying technology.

So, What Is the Best Practice for tools?

Well, I’m not sure I can define any ‘Best’ practice, but I have two rules that are my recommendations:

1. Use tools only when you know that the tool saves you time.

For example, using WSPBuilder to build WSP solution files saves you time since creating WSPs by hand is a time consuming and error prone task. The same applies to generating some core features, such as feature with receivers and web parts. And of course, signing the assembly and getting the strong name.

However, only start using WSPBuilder when you know how to build a WSP by hand so that if you find yourself in a situation where WSPBuilder does not suffice, you can still generate the WSP manually.

Or, perhaps even better, create your own tools. You may think this is a ludicrous idea, but remember that you have a personal development style and tools may not fit that style. Look for the tasks that are either time consuming or that you do very often and see if those tasks can be easily ‘toolified’.

One specific example for me is that I spend a lot of time working with multiple projects at a time. As such, I often have 5-10 different web applications, and I rarely remember which one is used for a certain project. Rather than running back and forth in Central Administration, I have created a small console application that lists the various web application and their root site collections. Using the external tool option in Visual Studio I now have quick access to the list of projects, web applications, and sites.

2. Use tools only when you know the underlying technology.

Let’s do some imaginary house building. If you had a tool that could build a house (let’s call it a house-building ray gun, since ray guns are cool) you could certainly get a lot of houses built in a very short time, and your customers would love you for it. As long as the houses that your ray gun can build are the kind of house your customers want. And, as long as the ray gun worked as expected.

However, you will learn nothing about building houses. Also, the next guy that gets a house-building ray gun will be just as competitive as you.

If your goal is to learn how to build houses… oh, sod it, I think the house-building ray gun has served its purpose. If your goal is to learn how to build SharePoint solutions, having a tool that completes everything, or most things for you, teaches you nothing.

Yes, this takes more time. It’s worth it.

So Why Are You Always Telling People to Use WSPBuilder?

I am actually surprised that I have received at least four emails asking more or less this exact question.

If you read my books, blog articles, or journal issues, you see that I usually start out using WSPBuilder, and for any definition of the word, WSPBuilder is a tool. So why do I do that?

In most of the writing I do, with the noted exception of Beginning SharePoint Development, I am not trying to teach you the underlying technology that WSPBuilder masks. Instead, I am writing about other features, or rather, I am writing about creating features, controls, pages, and other SharePoint artifacts. Most of the time, the primary use I have for WSPBuilder is to speed up development and deployment, and for generating some bare-bones features.

I only do that, however, because I know how to hand-craft a WSP if needed, I now which files should contain what CAML code, and I know how to install, deploy, retract, or upgrade solutions. These tasks are solved for me by WSPBuilder, and they do take time, so that’s why I’m using WSPBuilder.

The fact that I prefer to use WSPBuilder, however, should not deter you from making your own decision about which tool you prefer. Other tools, whether it is VSeWSS, STSDEV, or using no tools at all, may fit you better.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

4 SharePoint Warnings That Can Save Your Life

I happened upon one of those images showing a really weird warning, saying ‘Caution: This sign has sharp edges’. I’m sure you have seen it, it not, just Google it.

Anyway, I thought about this, and came up with a list of warnings that Microsoft should have placed on the SharePoint download site. Or pop up during installation. Or sumthin…

Warning: Heeding these warnings may lead to SharePoint success. Void where prohibited by law. Batteries not included.

Let’s get started.

1. Some assembly required.

Although Microsoft sometimes thinks so (or at least tells its potential customers so) SharePoint is not a product, any more than a box of tools is a house. Be prepared to get your hands dirty building most of what you need yourself.

2. SharePoint, while fun, should not be used as a flotation device.

SharePoint will not fix your organizational problems. SharePoint is a powerful technology, but if your organization is more of a disorganization, SharePoint will likely not help keep you afloat.

3. SharePoint teams may contain nuts.

When starting a new SharePoint project, don’t include just the technocrats and geeks in the team. Utilize people from the entire organization, including those wackos who do not believe SharePoint will create peace in the Middle East, cure cancer, or get you a date with Denise Richards or [insert your favorite actor/actress here].

For SharePoint to be successful, users are the key element; without user adoption, most SharePoint installations are as useful as square wheels.

4. Extended use of SharePoint may cause dizziness. If affected, do not operate heavy machinery or drive a vehicle.

SharePoint, being as versatile as it is, may cause your head to spin from all the possibilities. However, fear the feature creep in which you want to include more and more in your solution, and end up never finishing anything. I know you want everything in the world, but come one… Where would you put it?


So, what other warnings should Microsoft have put on SharePoint?


Pin It

This Blog Now Available on Kindle

If you are a Kindle user, apparently you can now subscribe to blogs and get automatic updates from those blogs.

I do not have a Kindle, and sadly, they’re not available here in Norway. However, I’m not going to let that stop you from reading this blog on Kindle.

In any case, I’ve made my blog available on Kindle so that you can subscribe to updates. It’s a paid service, and the price is set by Amazon, so I don’t control how much you need to pay. It’s currently $1.99 per month, but that may change. You get a 14-day free trial as well.

Check out the banner on the right, or go to Kindle Store to check out the options. Also, check out the other Kindle SharePoint blogs available for your Kindle.


Pin It