For the last couple of weeks we’ve been thinking here at Imtech ICT Velocity about how we could improve our SharePoint development process. During the last year we have gathered a lot of different tools which help us to automate the routine. And while they all are definitely very useful, they make the development environment quite complex. Maybe even too complex. One of the improvements we thought about was integrating all these different tools we have made into Visual Studio. Imtech Fields Explorer is the first one to go.
Via Jaap Vossers: Recently I’ve been pinged about a new SharePoint project on CodePlex called SharePoint InlineSiteSettings. What is does is to display the links to all Site Settings on the front-end saving you at least two clicks:
While working on SharePoint solutions once in a while you need to create custom Site Definitions. It’s not easy to work with Site Definitions: they can easily get very complex and are almost impossible to debug. Unfortunately there are situations when you cannot avoid using custom Site Definitions. Is there anything we could do to make it easier to work with Site Definitions?
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.