Inconvenient Pages List Name

While working on Microsoft Office SharePoint Server (MOSS) 2007 Web Content Management (WCM) Solutions you might have relied on the fact that the name of the Pages Library was always Pages. Well almost always, because in some languages, like German, it was translated along with the Title. Given that fact, changed the way we had to deal with the Pages Library in code. Instead of hard coding the URL part of the Pages Library, all of a sudden we had to retrieve it dynamically, just because someone accidentally translated the URL of the Pages Library. But looking at SharePoint Server 2010 tells us otherwise. Now the URL parts of Pages Libraries in all languages are translated. So was it a mistake in MOSS 2007 that in German the Pages Library was called Seiten or was it a mistake that the Dutch one was called Pages instead of Paginas?

Creating multilingual Site Definitions with Visual Studio 2010 SharePoint Development Tools

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.

Did you know: extending Solution Manifest with intellisense

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.

Logging to ULS in SharePoint 2010

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.