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.
Claims Based Authentication introduced with SharePoint 2010 allows you to login to a SharePoint site using multiple Authentication Providers. In some scenario you might need to determine which Claims Authentication Type has been used to login in order to conditionally show some content. Find out how this can be done using the new Claims API provided with SharePoint 2010.
SharePoint 2010 introduced Claims Based Authentication. One of the consequences of this is the fact that in order to use Forms Based Authentication (FBA) you need to configure your Web Application to use Claims instead of Classic Authentication. One of the many changes that you notice while working with claims are different login names: while in SharePoint 2007 you used something like myprovider:myuser, SharePoint 2010 makes the claims-soup of it: i:0\#.f|myprovider|myuser. And while this is something you can take into account for newly created solutions, it can get confusing when upgrading SharePoint 2007 solutions to SharePoint 2010, especially if all you need is the user name. So is String.Replace the only way to get it out or is there a better way?
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.