Content Query Web Part is probably the best solution for creating dynamic content rollups in SharePoint 2010. It’s lightning fast and because it’s using XSLT it allows you to easily change layout without touching your data. And although changing the presentation in Content Query Web Part is a matter of a few mouse clicks, it gets quite inconvenient when you start using custom XSLT files.
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.
The new Visual Studio 2010 SharePoint Developer Tools simplify the process of developing SharePoint 2010 Solutions. By encapsulating much of the plumbing of the packaging and deployment process they enable developers to create SharePoint 2010 Solutions easier and faster. Unfortunately in some scenario this simplification comes with a price and working with SPWebConfigModifications is one of such scenarios.
SharePoint 2007 shipped with the STSADM command-line tool which was meant to be used for all kind of administration tasks like installing and deploying Solutions. Although the STSADM is still available in SharePoint 2010 for backwards compatibility the recommended way is to use PowerShell instead. SharePoint 2010 ships with a great number of PowerShell cmdlets which simplify the process of administering your SharePoint Farm. And although PowerShell is way more powerful than STSADM, it adds some extra complexity.
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.