Net

SharePoint has a lot of gold under the hood. Unfortunately for us – developers not all of it is publicly available. Some methods/properties are marked as internal what makes it impossible for us to use is custom functionality we’re developing. But do you really develop your own alternatives or is there a way to get to those gems after all?

.NET 3x ships with a number of new features among which lambda expressions: an easy way to write code for querying collections. Because of its ease of use many developers use it for retrieving data from different kind of collections. Just recently I’ve been asked to have a look how well lambda expressions perform while retrieving data from SharePoint comparing to SharePoint native mechanisms.

Obtaining the value of a particular field (SPField) of a list item (SPListItem) is quite awkward. First of all you have to pass either the index, Id or the InternalName of an existing field. If the field exists a value of the object type is being returned. In some cases that value can be null. If it’s not you can cast it to its origin type as in most cases defined by the SPField.FieldValueType Property. Imagine doing all that each time you want to retrieve a field value. Isn’t there a better way?

Recently, while working on a new tool for converting XML files using XSLT I have noticed something odd: Visual Studio (VS) 2008 wouldn’t display the contents of the converted XML files!

In my previous article I have presented you a little test case I have made for testing the performance of various data merging approaches. Using an XSLT based method turned out to be the best performing way of merging multiple XML files.