SharePoint Rule #1: Do Not Modify SharePoint System Files
There are few reasons why you should never modify SharePoint system files located within the C:\\Program Files\\Common Files\\Microsoft Shared\\Web Server Extensions\\14 directory. The appeal of modifying SharePoint system files is that you can make broad sweeping changes to your SharePoint environment from the file system. With the exception of XML configuration files, modifying SharePoint system files can cause serious functional and supportability issues.
With SharePoint 2003 developers used to routinely used to modify system files to extend SharePoint functionality. Although modifying the system file solved the immediate need, it also caused serious long term issues. Many companies adopted a no patching policy because cumulative updates or services packs would overwrite customized system files causing code errors that would cripple the SharePoint environment. Additionally, receiving support from Microsoft in these situations was also difficult because the modification to the SharePoint system broke support agreements.
To alleviate these customization issues, Microsoft developed the solution framework as part of SharePoint 2007. The solution framework, still available in SharePoint 2010, allows developers to bundle their custom code and components for extending SharePoint within a single file called a solution. A solution file can be added to a SharePoint environment by server administrators. A solution can have multiple code modules called features. Each feature can be activated or deactivated to provide specific functionality to a server farm, web application, site collection, or sub-site. The power of SharePoint solutions and features is that new custom functionality can be extended and layered on top of the SharePoint platform and then removed as necessary. This allows developers the ability to customize SharePoint, still receive support from Microsoft, and to retract custom functionality as needed.
There are a lot of innovative ways to get around SharePoint to make the system do what you need it to do. You can use components such as site definitions, web definitions, list definitions, content types, field types, field rendering controls, master pages, page layouts, delegate controls, event handlers, workflows, feature stapling, web parts, user controls, server ribbon, claims providers, service applications, InfoPath, Silverlight, and http modules. If you find yourself reaching to modify the 14 folder remember not to touch it. It may take additional effort to come up with a solution, but in the longer run it will save time, money, and stress.
