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!