Thursday, October 16, 2008

Improve speed of development for SharePoint (Part1)

Listenning most of customers I work for, one of the bad point of SharePoint is the time that developments require to customize sites or extend SharePoint in order to give it more complete functionalities.
Customers often forget that if they had to do a SharePoint site from scratch using Asp .Net they would have had to rewrite some of the most appreciated SharePoint functionnalities like document libraries, security manager that can connect to company Active Directory, and so on. Anyway, it is right that sometimes, for a single functionality, it takes much more time to add it to a SharePoint site than to an Asp .Net site.
Why ?
I start writing this post looking for the reasons that makes sometimes a SharePoint project take so long time to be delivered, and in the same time looking for solutions that can improve development speed.
I will write later a chapter about deployment of SharePoint sites and explain that deployment tasks can sometimes take 30 % of the project full time even if you prepare your deployment, and that may take much more time if you don't do, with enormous risks to postpone the planned delivery date.
I also will write about graphical customosation, html + css and javaScript, that is also a big cost of time especially if you don't start well.
However, I prefer for the moment to focus on developement and try to look for practices to improve development speed in SharePoint.

First of all, why development are sometimes taking so much time in SharePoint project comparing to Asp .Net ones?

There is two main reasons:
  1. Most of the server code you will have to write will have to be built before having to be tested.
  2. You will have to deploy the code you've just written on your development machine before testing it.
These numerous operations of building and deployment set a lot of time especially if they come along with IIS reset. If you compare with a Asp .Net project, the developer in the case of a pure Asp .Net, write his client and server code, and test it by just pressing F5 !
So I will try to think about way of developping SharePoint code in order to be as close as possible to the Asp .Net developper experience.
So to avoid the two noticed previous points, there is obvious things to do :
  • using scripts
  • working directly on pages that are below the 12 directory.

- Using Scripts
You can program against WSS Object Model writting in line code in all the pages:
Master Pages
Layout Pages
Applicative Pages
Of course, for the two first type of Pages, it is a temporary solution, because it is not a best practice to use in line code in these pages since this code won't be able to execute if the page is customized.
Anyway, starting writiing your functionality using in line code will make you save a lot of time since you won't have to build your code before testing it. You won't have neither to deploy your dll an have to wait for IIS Reset or Pool Recycling.

So, I post something about script in SharePoint here.

- Avoiding deployment
To avoid deployment you have to develop code on files that are in the 12 directory. Files inside features for master pages and layout pages, file inside Layouts directory for applicative pages.
It would be great if, while working on your project file in Visual Studio, your code would be automaticaly pasted to the operationnel file in the SharePoint 12 of your development machine when you type a Ctrl + S.
So I did it.

Here is the VB .Net code for a Macro you can add to Visual Studio.

No comments: