One of the great capabilities of SharePoint Server is the ability of including reusable content: standard snippets of HTML which you can use in different places over and over again without having to copy & paste it. The great thing about Reusable Content is that you have the option to insert a reference instead of the copy of the content so that if the content snippet ever changes, you won’t have to manually check every single page in your site to ensure that the content is correct: SharePoint will do this for you automatically. While this piece of functionality is really great you wouldn’t believe how inconvenient it is to get to this list to add new content snippets in there.
When working on SharePoint Solutions one of the common requirements is delivering multilingual solutions. Depending on your scenario you might either need to localize a single Web Part or a complete Solution. Thinking of multiple languages you have to take into account not only the development but also the packaging process for all the different assets in your Solution. One of such assets, where implementing support for multiple languages in SharePoint 2010 might seem complex at first sight, are Site Definitions. However you can easily create a multilingual Site Definition using nothing more than the standard capabilities of the new Visual Studio 2010 SharePoint Developer Tools.
When SharePoint 2007 shipped with the Features and Solutions framework we thought we had it all sorted out. We were able to package our work and deploy it in a structured and repeatable manner. Using Feature Activation Dependencies we were able to ensure that all the functionality that our components require are available prior to provision our custom functionality. And while Feature Dependencies are definitely a great concept they are unfortunately incomplete. If all the different pieces come from a single Solution then Feature Dependencies are sufficient. However if your resources are spread across different Solution the only piece of feedback you will get from Feature Dependencies is message saying that a Feature with some id is missing in your Farm. Luckily this situation has changed with SharePoint 2010 and the introduction of Solution Dependencies.
Developing localized solutions on the SharePoint 2007 platform wasn’t as straight-forward as we wanted it to be. First of all you had to make your code support globalization and then you had to provision the localized Resource files to your Web Application. As SharePoint 2007 didn’t provide any mechanism to do that, you had to use custom Timer Jobs to get this done correctly. Luckily this situation has changed with SharePoint 2010 which introduces the new App\_GlobalResourceFile element in the Solution Manifest which makes it possible to declaratively deploy Resource files in a structured and repeatable fashion.
One of the pieces of developing custom components is logging information. No matter if it’s for diagnostic purposes or when an error occurs, logging allows you to track the health of your custom component. When developing custom components for SharePoint 2007 we hadn’t much choice. Although SharePoint 2007 shipped with the Unified Logging Service, we couldn’t use it. The SharePoint SDK was pretty clear about it: although some methods were publicly available, ULS was for internal use only and was not supposed to be used in custom code. Because of this, we couldn’t provide a similar logging experience to SharePoint and had to develop custom logging solutions. SharePoint 2010 changes this situation: using the new ULS is now supported and may be used for logging in custom code.