Defining custom Site Columns and Content Types is the very basis of almost every SharePoint project. Using Site Columns and Content Types you can define the information architecture of your Solution. And although this process is something that is very important and something you do very often, it is surprising how little support there is for it from the development point of view that would allow you to do it in a productive manner. CKS:DEV has already had some support around Content Types and Site Columns but still it was far from ideal, so including some improvements in that area was something we couldn’t really leave behind…
Creating custom Site Columns is something you do in almost every single SharePoint Solution. Unfortunately even in spite of great SDK documentation and intellisense for SharePoint XML files, it’s still a tedious process to create new columns directly in the XML. Using the SharePoint web UI is way easier but then again: how would you get that out of SharePoint and put into your Solution? There is an answer to that question and it is: use CKS:DEV!
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.
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.
SharePoint 2010 ships with a great developer story. The new Visual Studio 2010 SharePoint Developer Tools provide great experience and allow you to be productive while working on SharePoint Solutions. And while these tools ships with rich functionality they obviously don’t cover all new capabilities of SharePoint 2010. In some situations you might need to manually modify some of the SharePoint artifacts like for example when specifying dependencies for your Solution.