INTRODUCTION

Sharepoint 2007 (WSS 3.0 and MOSS 2007) has been a very-very great offering not only that it has so many great out-of-the-box functionalities, but it also allows us to build custom solutions on top of it. Basically, Sharepoint 2007 can be used as a development platform. However, few problems arise when doing team development with Sharepoint. It's not like a classic development methodology where everyone check-in/check-out code into TFS or VSS, and unit tests are applied, etc. With Sharepoint 2007, you just can do the development in so many ways. Microsoft also introduces Sharepoint Designer that allows you to edit ASPX and Master files directly. So, what about Visual Studio? What about source control? Sharepoint Designer has check-in/check-out mechanism. It's a source control application by default and you can also create customizations using Sharepoint GUI directly (creating custom content types, fields, lists, etc)? So how do we follow classic development methodology using Visual Studio if this is the case?

I personally have been involved with 2 types of Sharepoint project:
- Company-supporting application (eg. 1 massive Sharepoint app to support a company such as corporate Intranet)
- Client-based applications (eg. Internet websites)

My approach when doing these projects are quiet different especially when working in a team of developers since each of these projects has its own characteristics. These posts are written based on my experience only so I will appreciate your comments and your sharings of your experience, too. There are so many ways in developing Sharepoint so I would really-really love to hear how everyone is approaching Sharepoint customizations and development.

THE PROJECTS

1. Company-Supporting Application
This type of Sharepoint installation will be targeted for internal use only. It's normally used for corporate Intranet where all documents will be stored in Sharepoint. You will only have "1" project but with many features in it. In your source control application (TFS or VSS) you will store different source code for different features that support this massive app. Therefore, you will not have ClientA, ClientB node in it instead you will have something like MiningProjectSiteShell, ProjectDocumentLibraryFeature, etc. The source code is normally stored and owned by the company itself.

Branding is normally not a priority. Your solutions will normally evolve heavily around creating features for deploying workflows, feature receivers, custom lists, list receivers, content types and fields.

2. Client-Based Application
This type of Sharepoint installation is targeted for clients. This type of projects normally occur when you're working in a software development company. You will need to develop applications for clients. Therefore, your source control application (TFS or VSS) will normally have ClientA, ClientB, etc structure. Example of this project will be Internet website using either MOSS or WSS. The source code will normally be owned by the software development company and the deployment of these customizations can be done at client's environment or in a shared hosted environment.

Branding is normally a priority. Your solutions will normally evolve heavily around custom navigation controls (custom drop-down menu, side navigation and breadcrumb), content types, fields, master pages, page layouts.

THE CUSTOMISATION APPROACH

No matter what projects you are doing, you should never customize Sharepoint through GUI. I personally will never use Sharepoint Designer to modify master pages and page layouts because as soon as you modify these pages, they will be un-ghosted (ie. linking from file system will be removed) and you will be dependent on Sharepoint Designer from that moment. Same with content types and fields, you should never add a new content type/field through GUI.

You should ALWAYS put every Sharepoint customization into solutions and features! These include (and not limited to) master pages, page layouts, images, CSS, javascripts, content types, fields, list definition, event receivers, feature receivers, list receivers, web parts, etc.

Workflow however is an exception. I will tolerate workflow that is built using Sharepoint designer. Why? Because you can create SIMPLE workflow easily through Sharepoint Designer. The reason why workflow is an exception is because the only way for you to create workflow that can be deployed through feature is when the workflow is created using Windows Workflow Foundation and it can be very complicated. For simple workflows, Sharepoint Designer is allowed. For best practice however, still tries to develop and deploy workflow using WWF and features. That is to move away from Sharepoint Designer especially if you're thinking of modifying the workflow, updating the way it works, etc it will be best done using WWF, features and solutions.

Another reason why GUI customization should be prohibited is because, imagine that you have a team of 5 developers and each one of them has Sharepoint installed on their local PC/laptop. One developer needs to add a content type, how can that content type be replicated to the other PCs? The other developer needs to re-create that content type manually and worse, every developer has to keep track of what they change. If you miss one thing, that's it.....

I used to try to solve the above problem by using a shared development machine. So everyone connects to one PC that has Sharepoint in it. Fine...it solves the problem. One developer adds a new content type, the other developers can see it. But another problem arises. What if someone wants to debug his web-part? Remote debugger is attached. Once remote debugger is attached and the break point is hit, that machine suddenly stops working and other developers won't be able to even access the site and even worse, you can't attach more than 1 remote debugger at a time.

So the only approach left is, to build EVERYTHING using features and package them up into solution. You will then deploy the solution and Sharepoint will take care of copying the files to the correct location (the DLL to GAC, site templates to 12 Hive, etc). With features, you can now develop the customizations in Visual Studio, add them to source control app (VSS or TFS), you can also check-in/check-out as per normal development and everyone can get latest and upload the latest solution to their local development machine, you can schedule build, etc etc etc. There are just so many benefits of using features.

The disadvantage is however, it may take some time to setup features in Visual Studio. But it's worth it (at least it is from my experience).

THE DEVELOPMENT ENVIRONMENT APPROACH

I personally will install Windows Sharepoint 2003 and MOSS 2007 on every developer machine and I'm not a big fan of development using Virtual PC. The reason is, productivity. This is one and the only reason I have for not using VPC. Since the customizations will now be developed using features (and the features will be installed for a particular client Sharepoint app anyway), you can have multiple websites extended with Sharepoint on your local IIS, can't you? And it's just so much more efficient. VPC can be slow at times.

I've developed Sharepoint (both MOSS and WSS 3.0) for more than 10 clients and every time I want to modify something for a particular client I just go to my local IIS with customized HOSTS file eg. http://client1, http://client2 and I can access each client Sharepoint application on my local PC straight away rather than opening a VPC that corresponds to a particular client. It's really-really quick and I save so much space by not using VPC.

CONCLUSION PART 1

So....that's my experience in developing Sharepoint app for clients. In the next part I will share with you how I develop customizations using features, Visual Studio and source control and how I normally work in a team. Thanks, please share your experience.