Rules to Better SharePoint for Developers

Rolling out SharePoint solutions without a disciplined approach quickly creates brittle customisations, blocked release pipelines, and unhappy users.

Development for SharePoint is very different depending upon whether you are online or using On-Premises SharePoint.

• SharePoint designer can silently reformat your code and introduce errors.
• If you modify any master page or page layout file with SharePoint designer, it becomes customized. This means that SharePoint is now looking at a customized version stored in the database rather than the version on the file system. You then can't deploy future changes, because SharePoint will now always serve the customized version instead of the ghosted version in the solution package.

This is to prevent their work affecting other developers. During development, you can expect many of these things to happen:

• IIS resets may need to be done frequently, which stops the SharePoint website working.
• Custom web parts can easily introduce memory leaks which can stop SharePoint working.
• You may be running development SharePoint in debugging mode which would hold the server thread.
• You may be reading event or error logs that are being polluted by other developers simultaneously.

Thus, all SharePoint customization and development must be done on a Virtual Machine. No ifs, no buts.

1. It's very important to correctly setup a SharePoint environment for development. Correctly configured, this will save you a lot of trouble later on.
2. From time to time, you can seriously screw/damage a SharePoint installation during development and it is best not to install SharePoint on your day-to-day machine.
3. Additionally, when you start a new SharePoint project you don't want to carry all the baggage from previous customizations that could potentially affect your new project.

It's important for all your SharePoint Sites to be as consistent as possible. This helps users' navigation through new pages as they know exactly where to look.

Most people have now moved to SharePoint Online, either from scratch or by migrating content from previous versions of SharePoint. In SharePoint Online, a lot of legacy features have been deprecated and replaced by more modern counterparts. Unfortunately, chances are you have ported a whole lot of useless things as part of your migration.

[TODO: Screenshot of Useless stuff]

Before removing seemingly useless or old stuff, you should always make sure that site owners are OK with the deletion and that the data is actually not useful. In most cases however, the libraries detailed below have been added to your site by default and contain only demo and/or defautl data.

On intranets you always want a bunch of links easily accessible and customizable by the end users.

In ASP.NET deployment is a simple xcopy. Or you can right click the website project and "Publish website" in Visual Studio.

✅ Figure: Publish website in Visual Studio

In ASP.NET - Typically, the team will store the code on a source control system such as TFS (Team Foundation Server), check it out to their own local system, develop and test locally then check it back into source control for sharing.

In SharePoint - SharePoint comes with its own document control and version history out of the box. This is great for collaborating between developers and designers, but isn’t available for everything.

Differences - Unlike TFS, SharePoint does not support multiple check-out so each file can only be checked out to one person at a time.  The modification must be checked back into SharePoint.

This is the number one, and most important rule in working with InfoPath.

Always go for the lowest common denominator.  It sure beats realizing half way later that your form can't be hosted on SharePoint InfoPath Forms Services!

SharePoint allows you to create a Data Connection Library to hold all the connection information that Forms and Excel services can utilize.

You should always use a Data Connection Library.

In SharePoint, web configuration includes:

1. ASP.NET 3.5/4.0 library references – this is necessary for all the ASP.NET AJAX calls
2. Add system.web/pages/controls – to add additional tag prefix from System.W eb.Extensions
3. Add HttpModule (for example – to clean up extra JavaScript from SharePoint)
4. SafeControl tags for all custom dlls – in general these can be added via your solution package as well

ASP.NET is file system driven, whilst SharePoint is database driven. All SharePoint content and meta data comes from a database, including images, HTML, Master Page, etc. SharePoint provides a framework where components can be plugged in, and as a result these areas are improved out-of-the-box:

• Security model, membership, permissions.
• The UI framework becomes relatively consistent.
• Menus, navigation, and site maps.
• Administration of access i.e., site owners can change permissions for that site – without the need for administrators.

Deployment model is very different:

• ASP.NET has MSI file or XCopy deployment – individual server.
• SharePoint deployment is via Solution Package – but goes cross-site farms.
• Deployment is both declarative in (XML format), as well as in code with Feature and Event receivers.

Tools:

• ASP.NET is mostly done in Visual Studio .NET.
• SharePoint development is split among:
  • Internet Explorer – SharePoint configurations (note: non-IE browsers remain 2nd level and isn’t as good as IE with SharePoint)
  • Microsoft SharePoint Designer – SharePoint HTML page design and customization
  • Visual Studio .NET – custom web parts, custom workflows, solution packages

Microsoft SharePoint Technologies is built on top of ASP.NET technologies.  In particular, MOSS 2007 is based on ASP.NET 2.0, SharePoint 2010 is based on ASP.NET 3.5, SharePoint 2013 is based on ASP.NET 4.

Development for a SharePoint solution is always risky and may involve bringing down the server from time to time.  So we always customize and develop SharePoint solutions on a separate development server.  But when your development is done, do you know how to deploy your changes to the staging and eventually the production server?

• When working on packaging SharePoint artefacts into Features & Solutions, you should always make small incremental changes to your VSeWSS projects. Each time you should build & deploy to check you haven't broken anything.
• You should regularly make labels in TFS so you can quickly compare your changes against previous working versions to identify problems.

CAML is the XML definition for all things in SharePoint, in deployment, and in creating templates, CAML is the only format. In SharePoint development, you will also need to know CAML, in particular, how to write a query in CAML.

• Widely used in Content Query Web Parts
• Also used in SharePoint content reports
• In code, used by SPSiteDataQuery object

Each time you deploy a new package to your SharePoint site, you should add a new entry in the version list.

This will enable you to quickly find out which version of the package your SharePoint site is using, and let users know what version they are running.

These controls are similar, but the DVWP needs heavier customization and should be avoided where possible.

The CQWP is easier to style. The DVWP should only be used if you need one of these features:

1. You only want to search on one column in the list, rather than all the (indexed) columns.
2. You want to perform a search on multiple lists, but not all the lists on a web.
3. You want to have a very specific Look and Feel that the search results use.

SharePoint comes with some very basic workflows out of the box. A particular example is the content approval workflow.

When a content approval workflow is used, it modifies the process of publishing content to be:

1. User clicks publish (click 1)
2. Workflow starts, and asks the user to request for approval, there’s an option to add additional messages (click 2)
3. The workflow sends an email to the user to tell him an approval workflow has started. (email 1)
4. The workflow also sends an email to the approver(s) (email 2)
5. The approver receives an email, then returns to the page – they can Approve or Reject the workflow. (click 3)
6. Either way, a new workflow screen appears, with an option to add additional messages, the approver clicks accept (click 4)
7. The approval workflow completes and publishes the page.
8. It then sends an email telling the user that an approval workflow has been completed (email 3).

What is the problem?

The out of the box workflow is extremely generic. It has no customizations or shortcuts. Even if you are an approver, you cannot skip any of the steps. The end result is that you will have to click 4 times and receive 3 emails, for approving your own finalized content.

These kind of workflows are designed generic to fit any business’ needs – and in fact, businesses using these out of the box workflows have to adjust their staff’s workflow to match SharePoint’s ones. Which can be counter intuitive.