Standard for sharepoint development

My Current SharePoint Development Standards List
General

• All custom SharePoint work must be deployed through SharePoint solutions (.wsp files)
• All functionality and customizations must be documented
• Site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.

Code

• Web parts must be deployed using our custom feature receiver (we can provide source to third parties working with us).
• Custom code must be checked for memory leaks using SPDisposeCheck.
• For site definitions, use a minimal site definition with feature stapling.
• Use best practices when accessing data using the SharePoint object model. SeeWorking with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects

12 Hive Deployment

• No out of the box SharePoint files in the 12 hive will be overwritten
• Images deployed must be deployed into an RGA/ProjectName folder

SharePoint Designer

• SharePoint designer updates are generally not allowed. The only exception to this rule is for creating DataForm web parts.
• DataForm web parts must be exported through the SharePoint GUI and solution packaged for deployment as a feature.
• Editing out of the box master pages is not allowed. Instead, duplicate an existing master page, make edits, then solution package the master page for feature deployment.
• No SharePoint Designer created workflows. These are not portable and cannot be packaged for solution deployment.

InfoPath

• custom ASPX forms are preferred over InfoPath forms. They are easier to support, debug, and upgrade.
• InfoPath forms must be browser compatible. We run all our InfoPath forms deployed through forms services through the browser.
• If the InfoPath form has code behind or needs full trust it must be solution packaged and deployed through central admin.
• If InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form. Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.

Working with SPSiteDataQuery and CrossListQueryInfo

SPSiteDataQuery & CrossListQueryInfo

I was about to write an article to explain SPSiteDataQuery & CrossListQueryInfo,When I came across this well written article.
Here is the snippet

SPSiteDataQuery :

    string lists = "";

string viewFields = "";

string webs = "";

SPSiteDataQuery siteQuery = new SPSiteDataQuery();

siteQuery.Lists = lists;

siteQuery.ViewFields = viewFields;

siteQuery.Webs = webs;

results = SPContext.Current.Web.GetSiteData(siteQuery);

This query returns the title of all items in Issue lists in all sites in the current site collection.If you are running Microsoft Office SharePoint Servers, you can also use the CrossListQueryInfo object to query for content. The advantage is that SharePoint has a caching mechanism for the queries that you run. By using CrossListQueryInfo, your webpart will use this caching mechanism. And you can also make use of audience targeting.

CrossListQueryInfo:

string lists = "";

string viewFields = "";

string webs = "";

CrossListQueryInfo query = new CrossListQueryInfo();

query.RowLimit = 100;

query.WebUrl = SPContext.Current.Site.ServerRelativeUrl;

query.Lists = lists;

query.Webs = webs;

query.Query = "";

query.ViewFields = viewFields;

CrossListQueryCache cache = new CrossListQueryCache(query);

results = cache.GetSiteData(SPContext.Current.Site);

Click here for complete article.
Following is a description for the available types (available in the WSS SDK)

Type:

Value Description
100 Generic list
101 Document library
102 Survey
103 Links list
104 Announcements list
105 Contacts list
106 Events list
107 Tasks list
108 Discussion board
109 Picture library
110 Data sources
111 Site template gallery
113 Web Part gallery
114 List template gallery
115 XML Form library
120 Custom grid for a list
200 Meeting Series list
201 Meeting Agenda list
202 Meeting Attendees list
204 Meeting Decisions list
207 Meeting Objectives list
210 Meeting text box
211 Meeting Things To Bring list
212 Meeting Workspace Pages list
300 Portal Sites list.
1100 Issue tracking
2002 Personal document library
2003 Private document library

BaseType

0 — Custom List
1 — Document Library
2 — Not used
3 — Discussion Forum
4 — Surveys
5 — Issues List
so, if you are developing custom picture library set Type="109" and BaseType="1" (because picture library mainly based on document library)

Sharepoint Devs VS ASP.NET Devs

Microsoft has been very successful to promoting their SharePoint product, even though SharePoint has been around for a while, there 2007 and now 2010 version is something every organisation wants. 

With Microsoft practically giving away SharePoint licenses to organisations via EA agreements – we are reaching a very unique and rather unexpected situation where the demand for SharePoint developers is surpassing the demand for Web developers.

This shift in demand are forcing IT departments and Web Development companies to reduce the size of the web development teams and increase the size of their SharePoint team, in other words, take staff originally hired for web development and get them into SharePoint development.

This is currently the "normal" approach in getting SharePoint experts, many IT Recruitment companies still don’t understand this shift in demand, and are not yet focusing in the SharePoint space, some recruiting companies haven’t even heard of SharePoint and see it as a specialist skill.

Restructuring organisations to handle the shift in demand is a change that will naturally lead to resistance and conflict. To the managers and other decision makers, this change seem minor, especially when “converting” ASP.NET developers, since SharePoint is built on ASP.NET, and it is assumed that the same skill set and approach is needed with minimum training on the SharePoint basics. That is not the case. 

An ASP.NET web developer became a web developer by studying and gaining experience in the following...

• HTML
• CSS
• DHTML
• JavaScript
• JQuery
• ASP.NET (C#, VB, etc)
• SQL
• AJAX

They also use a range of products created especially for ASP.NET web development, mainly... 

• Visual Studio
• SQL Server Management Studio
• Some code repository like SVN or Team Foundation Server

That’s the tools they have in their tool belts, over time, they become experts by continuously applying this skill set and learning the best approach in using them when completing tasks.

For SharePoint, the approach is different, very different. All the HTML, CSS, JavaScript and so on is provided by the SharePoint product, SharePoint experts are not suppose to touch that space, deploying SharePoint solutions is more focused on planning, installing and configuring, with less emphases on developing.

If development is required, it’s because SharePoint cannot satisfy the organisations unique requirements “out of the box”, and something “custom” needs to be built. Custom development in SharePoint is regarded as the last resort, while an ASP.NET developer sees this as the first option, placing them in a situation they are not comfortable with right from the start.

Since a SharePoint solution is different from standard ASP.NET web applications, tools like Visual Studio and standard code repository tools have their limitations and the Web Developers are forced to use another tool, mainly SharePoint Designer, which is another learning curve hurdle that can limit adoption.

If the bulk of the SharePoint project is focused on planning and configuration, then the skills that the developers were perfecting as an ASP.NET developer no longer drives the success of the entire solution, but rather the success of a small component (if any custom development was required).

The SharePoint developers are also faced with a challenge that they never experienced as an ASP.NET developer, there are restrictions when developing and providing a look.

An ASP.Net Developer is used to having full control over every component of the web application, from its functionality to its look. SharePoint is a product with a large amount of functionality built in, and developers need to configure the required functionality and make it available to the end user. 

They need to move away from creating a SQL database, the foundation of their solution, and move towards using the existing SharePoint database via SharePoint lists. 

Look and feel is template based; adjusting the default look usually creates an environment that SharePoint is not expecting that can lead to drop in functionality (Read my Post for more details). 

SharePoint may add these restrictions and limit what the developers can do but the end users are unaware of these restrictions and expect all their unique requirements to be for filled. It’s not the end users fault, there requests don’t seem unreasonable, it’s just that SharePoint was not built to work that way, the following are example of “simple” requests that cannot be done via SharePoint without something custom being done:

• “I would like my site to have 3 navigation menus” – SharePoint manages a Global Menu (Site Collection Specific) and a Current Menu (Sub Site Specific) only, that’s 2 menus.

• “I would like my menu to hover down to 3 levels” – SharePoint Global Menu hovers to 2 levels only, SharePoint Menu Configuration screens do not allow the levels to be modified.

• “I want to use an AJAX/Silverlight menu” – It is not recommended in SharePoint 2007, this is explained in detail in my previous post.

• “I want the same menu across my entire site, all managed in one place“– Global Menu is Site Collection dependant while the current menu is sub site dependant, a different site collection or subsite means a different menu, managed in a different place.

I limited my examples to SharePoint navigation menus only, just to show you how onecomponent can give a developer a big challenge from “simple” requests that would have been a lot easier to complete if the SharePoint was not used.

So what does this tell you? Demand shifts are forcing managers to turn web developers to SharePoint developers. This is not what web developers signed up for, the approach for these projects is very different, and in many ways restrictive and frustrating, so they don’t do it, leading to the shortage in SharePoint skills.

How do we solve this problem? Stop looking at converting Web Developers, when seeking SharePoint Developers, unless the developer shows a strong interest in SharePoint, you will have a lot of resistance in this change, rather get the ASP.NET developer trained in custom development for SharePoint only, the skills required for that are the skills web developers are already comfortable with, and focus on getting different set of people for SharePoint installation planning and configuration.

Another approach is to understand the purpose and restrictions of SharePoint and communicate that to the end user so there expectations are well managed; unrealistic expectation places unnecessary pressure on the developers which leads to frustration and will draw them away from SharePoint development.