I was working on a bug today on a customised List Viewer which I’d inherited. The guy who wrote it was plainly a very clever chap and knew his SharePoint internals unfortunately even against his own advice on his blog (which I won’t include here), he added in some key functionality which depended upon a call to an internal method inside the Microsoft.SharePoint.dll.
list.GetType().InvokeMember("SetViewRenderQueryParameters", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.InvokeMethod | BindingFlags.Instance, null,list,new object[] { context, currentUrl, web, listName, viewGuid,designerView, gridview, instanceID, selectedID, filterString, rootFolder, folderCtId, paged, pagingTokens, lastFilterIndex });
Unfortunately, what he said could happen, did happen. That is Microsoft updated Microsoft.SharePoint.dll and changed the signature of this method, and added in a new argument prevPaged! Therefore the InvokeMember failed and not surprisingly, so did the custom list viewer.
The fix was easy enough thanks to Red Gate .NET Reflector, determining the correct signature was no problem, and the code was suitably updated, but really it needs a better way to do what has been done, as there is no guarantee that the same won’t happen again!
So the lesson is, stay away from using private members internal to DLLs to which you do not have the source code, the author is under no obligation to honour any contract with the outside world, that’s why the method is private …. the clue is in the name …
Cheers
Dave Mc
Dave Mc's Blog 
Leave a comment