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.

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!