SharePoint 2010 ships with the great ability of adding Web Parts to content areas. This allows you to easily extend your content with dynamic elements providing your users with richer experience. Similarly to using Web Parts with Web Part Zones you should include Web Parts in Rich Content in your structured and repeatable deployment. There are however a few differences in how you provision Web Parts to Rich Content and knowing how it all works can make your life easier.
Programmatically granting permissions in SharePoint 2007 wasn’t that very complicated. You could grant permissions either to a User or a Group and in order to do that all you needed was a reference to that User/Group. As you might have heard SharePoint 2010 supports claims based identity what allows you to grant permissions using the identity of the user rather than a specific way of authentication. If you’ve looked through the public SharePoint 2010 API you might have noticed that there is no specific method that allows you to programmatically grant permissions to a claim. So how do you do that?
Last year I wrote an article about programmatically provisioning Variation Hierarchies in SharePoint 2007. The point of that article was that there was really no way you could provision Variations in repeatable way in a supported fashion and had to use reflection to get the job done. The situation in SharePoint 2010 has changed a little. The process of creating Variations has been made more reliable my moving it completely to a Timer Job. So a new approach, requires new code, and here it is.
One of the great improvements in SharePoint 2010 are Web Templates. Mirjam van Olst wrote recently a great article about why using light-weight Web Templates is a better approach than using full blown Site Definitions. While using Web Templates for creating sites and Site Collections is pretty straight-forward things get complicated when you need to create the Site Collection programmatically.
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.