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.
A few months ago, I had an assignment for a multinational beverage company to implement a publication system for their products across Europe. Along with a few other consultants and managers from another unit in my company, they had decided to go for a SharePoint solution as this seemed to meet all business requirements: centralized master data management with the ability to generate XML – and Word (or other human friendly) documents.