As I said in my last post, I see some pieces of (ugly) code recur far too often in SharePoint. Probably most pervasive is the one to allow and not allow unsafe updates. In this post, I’ll provide a proper solution for this matter.
There’s one specific error that keeps coming back when I create new SharePoint solutions that require multiple assemblies next to the farm/sandboxed solution. Continue reading
Every once in a while you’ll have a situation in which you temporarily have to use different (shared) settings and reset them if all work is done. An example of this is often seen in SharePoint, for instance disabling events when updating items in event receivers, or allowing unsafe updates. A workaround that I have seen a lot is that developers add a TRY/CATCH/FINAL block for each method they want to reset some objects. In this post, I’ll talk about an alternative way of achieving this behavior by the implementation if the IDisposable interface.
Console applications provide a quick and easy way (and also a little bit dirty) to test or fix parts of your application. It enables you to focus on the business logic rather than the GUI. Sometimes the output to the window is quite large – larger than the console window can show. In those cases you want to be able to persist the output to text files. In this post, I’ll show you how to do this.