This is the second part of Sharepoint Development using Visual Studio series. For previous part:
http://www.sharepointblogs.com/tommysegoro/archive/2008/09/04/sharepoint-team-development-with-visual-studio-part-1.aspx

 

INTRODUCTION

I've shared to you about the type of projects and the development methodology approach on my previous post. I really-really thank everyone who has contributed and spending their time writing comment on my previous post. Thank you for your sharing!

This second part I will talk about planning the development. Once again this is all based on my previous experience only so any comments/sharing from you will be much much appreciated! I always believe that there is sky above sky and I always believe that there is no one who can do everything...some people are good at one thing and another people good at other things. So please write comments, please share, please disagree or agree with me. Thank you very much.

 

THE REQUIREMENTS GATHERING

This is what I found as the biggest part of the development process: the planning. In my experience the planning will decide how your development process is going to be. It can be easy or it can be nightmare. The first planning we have to do before start developing on Sharepoint is to GET THE CONTENT TYPES AND FIELDS RIGHT. I always do this as my first step. The reason is, as someone pointed in my post regarding updating content types and fields, Microsoft only supports limited method of updating fields. Please read it here.

I've ever developed a MOSS website for a government body that has more than 20 content types and more than 100 custom fields! And yes...we didn't get them right in the first place and the manager pushed us (the poor developers) to make the system available in UAT so that client can START INPUTTING CONTENT!. This is WRONG WRONG WRONG....at the end of the day, we wasted so much time updating the fields because we didn't get them right in the first time. We ended up changing some fields from Text to HTML because they need more than 255 characters of content in that particular field, etc. It was pretty bad....

In a modern development methodology, Agile development allows you to not have the full set of requirements in the first place. Change requests are allowed and can be handled very well with this methodology. However, with content types and fields, for me personally (at least from my experience), they have to be done right in the first place. Additional fields are OK because when you de-activate/re-activate feature, they will be added successfully. But changing field types, etc will be very hard for existing fields.

The other part of Sharepoint (custom controls, master pages, site definitions, event receiver, feature receiver, workflows, etc) can be updated quiet easily using feature/solution deployment. So with these, you can apply Agile methodology (ie. You don't have to get the design right in the first time for you to be able to write custom controls, do you?).

 

THE PROCESS

1. You should define your content types and fields first
2. You should NEVER get users/clients to put live content before the fields and content types are done correctly. This should be done after the content types and fields are finalised. This will just screw your project plan because as I've mentioned earlier, modifying existing content types and fields are just so hard and we don't want to re-flush the site (ie. delete/re-create site collection) and re-activates the new fields and content types and lose the live content thas has been put in the test site, do we?
3. Other Sharepoint elements (master pages, page layouts, DLLs, etc) can be developed ad-hoc. You don't need to get them right on the first time. They can always be upgraded with solution/features easily.

 

THE TOOLS

As I mention earlier in my first post, we HAVE TO USE feature and solutions deployment and thanks to everyone who contributed about the workflow deployment. Yes, it's the best practice to deploy everything (including workflows) using feature and solution deployment. Therefore, we will need a tool that enables us to do this especially for doing it from Visual Studio.

The tools that I mention in this blog are once again based on my experience only! Of course you must have other methodologies for creating features and solutions automatically. The tools I will be using are (including their advantages and disadvantages which are also only my opinions, you can disagree/agree with me):

STSDEV

Advantages
- Built-in Visual Studio build commands. You can run install, deploy, upgrade, delete, etc from Visual Studio directly. Just build your project and it will do the job for you. You don't need to open command prompts and remembering the lines!
- Auto-creation of manifest.xml and DDF files and auto-creation of CAB/WSP file which is great.
- If you remove files/folders from RootFiles, they will be reflected straight away in manifest.xml, DDF and WSP.

Disadvantages
- You have to use the project type selector for creating a particular project. I tried to use the Blank Solution without DLL (C#) project before for creating features and guess what...somehow the files within the feature (except feature.xml and elements.xml) are not deployed! They're in the CAB and WSP but they're just not deployed to the FEATURE directory. Maybe I didn't do it right but anyway...one thing that I'm hoping STSDEV can be improved is it should be generic for ALL type of Sharepoint projects (regardless it's web part, feature, etc). The project selector will only create a set of files/folders inside RootFiles for a particular project so user will not forget. For example, if I select the Web-Part project, the project selector should create folders and files required to deploy a web-part. It should not fail if the web-part project is used to create features.
- Inclusion of DLLs are manual. If you add a reference to another project that will add a referenced DLL, you have to specify it in SolutionConfig.xml manually.
- It creates one Visual Studio solution per project. Additional configuration will be required for you to be able to aggregate STSDEV projects into one solution.
- You cannot control the creation of the DDF file. At the moment I found a problem where you can't set the .Set MaxDiskFile property of the DDF which will allow the CAB file to be bigger than 1424KB. Therefore, if you have so many files in your CAB file and it exceeds 1424KB, they will be truncated. The work around for this is to let STSDEV build the DDF, you set the MaxDiskFile property manually then you build the CAB manually and not using STSDEV.

GERALD DE RUN (Microsoft consultant)'s SOLUTION TEMPLATE

I've met him before in my previous workplace and he introduced to us his solution template. Please read his blog here. His solution template is utilising POST BUILD event to create manifest.xml, DDF and WSP.

Advantages
- The template is generic for everything (web part, features, etc) and the files will be deployed successfully in FEATURE folder.
- Has built-in Install.cmd, Upgrade.cmd and Uninstall.cmd.
- Can aggregate many projects into one solution.
- A switch in post-build event will allow you to add all referenced DLLs to the deployment project (hence in WSP) automatically.

Disadvantages
- No Visual Studio built-in commands. So you have to open command prompt and run the script
- Since it's using 2 projects, one is the deployment project and one is development project, the way it works is, it will copy the files from development project to the deployment project using post-build events then in the deployment project, there is another set of post-build events and scripts that will then create manifest.xml, DDF and WSP. With this configuration, the files are not automatically deleted from the deployment project. If you remove files/folders from the development project, the removal from deployment project is manual. So you have to create a custom tool (which I have done) that will allow you to delete files/folders from deployment project hence removing them from the WSP.

I personally go down Gerald De Run's path and modify his solution template to be Tommy Segoro's solution template that has some fixes to some of its limitations. There is no reason at all for me for not using STSDEV. Why I use Gerald's solution template, because I knew about it before STSDEV (hence comfort zone).

My point is, it's not important about what tools you're using as long as creation of manifest.xml, DDF and WSPs are automated. If you've used STSDEV please continue using it. It's an excellent product! If you're still interested with my modified-Gerald-De-Run's solution template, please go to http://www.sharepointblogs.com/tommysegoro/archive/2008/09/12/visual-studio-2008-sharepoint-solution-template.aspx.

 

CONCLUSION

So there you go....remember, get the content types and fields right first before you get into trouble.

---

Posted 09-08-2008 9:28 AM by tommysegoro