The SP Developers Basic Tool Belt
More than a few people, including those not in IT, find themselves in the world of SharePoint development by tinkering around and trying to find ways to make their jobs and lives easier. Regardless of how they got there, there is a basic toolset that everyone who develops should know about.
The core tools, made by Microsoft, are essential and powerful. They are SharePoint Designer, InfoPath, Visio, PowerShell, and Visual Studio.
SharePoint Designer is for small projects that will not grow very large. It is for simple solutions that need to be deployed to only one place. On the other hand, SPD has numerous issues and it is a poor choice for almost anything complex.
The gain does outweigh the pain in some instances since some solutions or workflows that would take hours or days using a traditional coding approach can be completed quickly with SPD. It is wonderful for quick integration solutions or simple workflows. There are also many things that have to be started in SPD before they can be cut and pasted into Visual Studio projects. Many ASP.NET developers who turn to SharePoint avoid this tool and look down upon it as a lowly or beneath them because they believe it is too simple or too error-prone. This is an easy mistake to make as it really should be viewed as another tool in their tool belt.
Word of warning: if you ever save anything you have edited in SharePoint Designer keep a backup in notepad or Word. SPD may delete segments of your page if it believes them to be invalid.
InfoPath is the standard tool to create custom website forms that users can complete and submit. InfoPath is like SPD in that it is best for small web forms with simple to moderate complexity. Web forms can be created here much more quickly than in Visual Studio, and they can be deployed much more simply. In fact, it is a wonderful tool as long as the form needs to be located in only one place and can look like a mid-90s web form. The more complex the form, the harder it is to get InfoPath to cooperate.
Many may ask, why not just use the out-of-the-box forms that are automatically developed when a list is made? You can. Where InfoPath steps in is that it expands your options. It allows for basic conditional rules on different form fields (for example; if field “a” is true then field “b” is visible) and it allows for field validation such as requiring only valid email addresses in a particular text box.
InfoPath is also unique in that it can easily bring together and manipulate data from different places. It also allows information submitted from the form to be sent to many different places at once, such as to SharePoint, email and another system altogether.
This biggest catch here is that you need to be running enterprise licenses in order to fully leverage InfoPath within SharePoint.
Visio is not truly a development tool, but close enough to be worth mentioning. Visio can be used as the drafting tool for SharePoint Designer workflows. After the workflow is drafted, notes and commentary on the proposed workflow can be collected, and then the workflow can be exported or directly opened in SharePoint Designer. SharePoint Designer 2007 can export, but not open Visio workflows. Sadly, Visual Studio cannot open these files. Regardless, know that having finished a workflow in Visio does not mean that development is complete.
This is a nifty tool if you have a team of people who need to collaborate on a workflow before it is added.
This is another odd-duck. PowerShell is not exactly a development tool, but a scripting tool that allows you to make changes to a SharePoint environment in one of two ways. Either you can open the PowerShell application and send commands from its command line, or you can write a script and run it as you would run an application.
Despite an early learning curve, developers, architects and system admins should look at this as a quality of life improvement tool. If you have to constantly repeat an action such as a deployment, then PowerShell is the way to go. If you need to conduct a serious investigation into the state of a farm, site collection, site or list, then turn to this tool.
Visual Studio is the wonderful behemoth that intimidating to those who have never used it before and even many of us who use it almost daily. It has the potential for great things and great frustration. Regardless, this is the power tool that should be used for almost anything beyond simple projects, the notable exception being some mid-sized web forms.
The main weakness of this tool is that there are simply not enough SharePoint templates and functionality. Thankfully, the SharePoint development community has been hard at work on a Community Kit for SharePoint. This is a must-install for Visual Studio and is free and available from Codeplex.com. With this you can develop most SharePoint projects you come across.
Your Tool Belt Doth Overflow
You may be thinking “OMG, I need to know all that!?” And the answer is: maybe. Some people need to know all these tools and more. For the novice developer, only a few are really necessary. The point is that everyone who develops with SharePoint should at least know which tools are the in the basic SharePoint development tool belt. Everyone should experiment as time permits and work requires. I would love to hear back from people on what tools are their favorites. Please feel free to use the comment section below to share your experiences with these and other SharePoint development tools you think we should be aware of.