Introduction
Last month, I attended the European SharePoint Conference held in London. Overall the conference was a success and everybody learnt a lot from SharePoint MVPs, who are best in delivering what they know. I wrote down my notes during the conference and decided to share best practices discussed in the sessions that I had attended. Once I will receive the DVD of all sessions, I will update my blog to provide more information on best practices discussed in other sessions.
Session: Best Practices for developing a SharePoint Web Part (Presented by Todd Bleeker)
- Naming Convention for choosing library name
CompanyProject.Contents.Purpose
e.g. PMCentrix.WebParts.Navigation
- Naming Convention for Choosing Web Part class name
[Purpose]Part.cs e.g. MyTasksPart.cs
- Path of User Controls
- Create a folder under ..[12 hive]\template\controltemplates\UserControl\
- Create a User Control folder for a place to deploy all of your user controls
- Inherit Web Part class by using ASP.NET Web Part Library to develop a web part
- Always use CreateChildControls() as an event to write your code
- Never use
Render()
event of a web part - Never use
RenderControl()
event of a web part - Rarely use
RenderContents()
event of a web part - Avoid using
OnInit()
event - Always call the Base Class method before even your
try... catch
statement
- Must sign and give strong name to your web part assembly
- Consider deploying your web part assembly in the web application BIN directory instead of GAC, i.e., Prefer to use Code Access Security (CAS) instead of Global Assembly Cache (GAC) for deploying web part assembly
- Benefits of deploying Web Part assembly into BIN folder:
- Fastest iterative approach i.e. code, compile and refresh
- No need to recycle application pool of web application
- Use Static Version for versioning of your web part assembly
- WSPBuilder is an industry tested tool for creating a deployment package for your web part, so why not use it.
- Use Web Part properties and avoid any hardcoded text
- Call EnsureChildControls() procedure before writing your web part code in the
CreateChildControls()
event
Session: SharePoint, SQL Server Storage Best Practices (Presented by Mike Watson)
- SQL Health is equal to SharePoint Health, so never only consider the sizing matrix of SharePoint
- How to scale SQL Server: You have two options; Scale Up i.e. by adding more memory or adding more SQL Servers in the cluster or Scale Out i.e. Add another SQL Server after every 1TB of content space
- Scale Out is more flexible for replication operation but Scale Up is more cost effective
- Best Practice: Allocate 10% of overall SharePoint Content or 300GB disk space for Tempdb database
- Allocate separate and dedicate disk space for logs
- Best practices for choosing RAID level:
- Use RAID 10; why??
- Better redundancy
- Faster and less impacting rebuilds
- 2 * write performance
- Optimised for IO operation
- Disadvantages:
- Expensive
- Lower your overall disk capacity
- Use RAID 5 when:
- Storing content
- Content is replicated
- SQL failure is automatic between content
- Issues with RAID 5:
- Recovery takes longer
- Slow for write operations
- Risky
- Best practices for network bandwidth (Gigabit or better network)
- Extra attention should be given to MySite. MySite takes more time to render than team site
- Never program SharePoint database to use autogrow
- 64-bit hardware for SQL Server is recommended
- Use multiple data files for SharePoint database, i.e. number of data files = number of CPU core
- Defragment your databases regularly
- Use differential backups
- Don’t virtualise SQL Server
- Ideally don’t exceed 5 web servers per SQL instance
- Scale SQL Server Out as you add more SharePoint servers
- Prioritise your SQL Server Hardware in the following order:
- SQL Server à Index à Excel à Search à WFEs
- Best practices for virtualisation
- Hardware guidance does not change in virtualisation
- i.e. 4 processors physical = 4 processors virtual
- 16GB RAM physical = 16GB RAM virtual
- Use Pass through or fixed VHD
- Don’t use dynamic disk in a production farm
- Network is tricky. Use multiple NICs and NIC teaming on the hosts
- Isolate Shared Services Provider (SSP) under the following circumstances:
- 10 million items indexed
- Multiple farms consuming shared services
- 100K user profiles + people search + my sites + significant use of audience
Any combination of two or more from the above are true.
- Index Server does not index all versions because you get search result of only latest content
Session: Best Practices for developing Custom Field Types (Presented by Todd Bleeker)
- Custom Field Types do not work with datasheet view and Microsoft Office application, i.e. in Information panel
- You must sign custom field type assembly and deploy to GAC
- Naming convention for custom field types:
- Field: [Purpose]Field.cs
- Control Class: [Purpose]FieldControl.cs
- Value Class: [Purpose]FieldValue.cs
- Field types_[Purpose].xml
- Always use HTML Encode, when you render to prevent Script/SQL injection hacks
Notes From Other Sessions
Category: MOSS 2007
Published: 02/05/2009 22:39