Rules to Better SharePoint Development
Since 1990, SSW has supported the developer community by publishing all our best practices and rules for everyone to see.
If you still need help, visit SharePoint Server Consulting and book in a consultant.
Do you agree with them all? Are we missing some? Let us know
what you think.
Team Foundation Server is the fully integrated solution to manage projects, giving developers, testers and management a single source of truth for all project needs.
Project Managers and stakeholders will love:
- TFS's integration with code/SQL/SharePoint which provides a dashboard with project reports, giving them greater visibility of the project status and burn down lists
- The easily customization of the data using Excel Web Services
Developers will love:
- TFS 2010 for the SQL and SharePoint Server Explorer and the integration of viewing, creating and deploying
- That they don't have to try to interpret a bug report from a tester, and then they have to reproduce it. Why? Because of Intellitrace, which allows you to double click and open to the exact line of code with the variables set.
- Seamless source control
- No waiting for compiling and tests to run. The integration with the build server (continuous integration) is the biggest productivity boost you can give a developer
- SharePoint Wiki
Testers will love:
- The many ways of automating their manual tests via:
- Web tests
- Performance tests
- And the jewel in the crown, Coded UI Tests
- The fact they never have to spend time reproducing a bug before documenting it
- And it gets better, they don't have to document it because testing tools recorded what they did
- Later on, when they decide to go with Lab Manager they will never spend time setting up that special environment (say running windows 95 and IE6)
Managing your SharePoint Projects with TFS (with proven Agile/Scrum and ALM Strategies)
In ASP.NET deployment is a simple xcopy. Or you can right click the Web Site project and "Publish Web Site" in Visual Studio.
- Fugure: Publish Web Site in Visual Studio
In SharePoint the way to deploy a set of changes is via a solution package.
SharePoint provides additional layer and infrastructure on top of ASP.NET - part of this layer is the support for administrators (who may not be developers) to quickly add, remove, activate and deactivate features across a SharePoint site farm.
These are awesome features and something that basic ASP.NET does not have, but it does add additional development overhead to build the solution packaging.
- You need to create such a package via VSeWSS (or a similar tool such as WSP Builder)
- Add entries for all the files you want to include in the package
- Update and get the latest version of the files from development SharePoint or TFS
- Compile the package into a WSP file (which is a cab file)
- Test the package on a staging server.
- Deploy it on a production server.
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.
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.
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.
We think the following are best tracked on a development SharePoint server:
- Master page
- Page Layouts
And these should not (or cannot) be version controlled on SharePoint server:
- Low level customizations such as custom web parts should still be developed in VS.NET and stored in TFS.
- Package files to build solution packages should be stored in TFS.
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.
Data Connection Library provides a central location for defining all the connections to various data sources within your company.
- It allows you to change the data source definition in one place, without having to worry about changing the same definition in 50 forms and excel spreadsheets.
- A centralized data connection library also helps your users to locate data easily.
- Your users don't want to know the intricate details on how to get a particular data - they just want the data and have the form working! So if you as the administrator provides it for them, they will love you, they will use it, and you will have an easier time managing your SharePoint site!
To create a master page or reuse an existing master page is a time-consuming process. Because you have to determine what the Office SharePoint Server 2007 page model requires — necessary content placeholders and controls to work with the page layouts.
Another problem of Default.master is that it contains many tables that are difficult to style.
- <%@Master language="C#"%>