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?
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.
SharePoint 2010 ships with Developer Dashboard which allows you to see how well different pieces of SharePoint are performing. And while it’s extremely useful by itself, it becomes even more important when used to measure the performance of your custom code!
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.
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.