I haven’t really done much blogging lately so I figured I’d try and get back into it by sharing some scripts from my collection. Over the years I’ve created tons and tons of little scripts here and there to help me solve one problem or another – whether it be some upgrade related thing or a content or build migration or just some random snippet to help me figure out what the heck is going on with my code or with SharePoint in general – I’ve got a ton of them just scattered all over the place. So at various points this summer I’m going to try and just grab an arbitrary one here or there and clean it up some and post it so others can benefit (and also to force me to clean up some of my crap).
The script that I want to share today I created a couple of years ago to help me troubleshoot an issue I was having with a custom delegate control registration. The problem ended up being resolved easily enough as it was simply an issue of scope – the control was registered at one scope but expected at another. Of course, at the time this didn’t really make sense as the scope that should have been expected was what I was providing, turns out that there’s what I would characterize as some bad design decisions within the SharePoint product so what I expected wasn’t what SharePoint wanted. Anyways, I digress – to help me isolate the issue I threw together a quick little script which would dump out the control registrations so that I could validate that my control was in fact being registered and being registered at the scope I expected. I could also use the script to see what was the “top” registration, or specifically which control would actually win and get its code called and rendered on the page, and finally, I could use this to see what other controls I was boxing out for the win (or loss). The script below is a much cleaned up version of my quick and dirty hack but it does the same thing, just with comments and a little more flexibility with the use of the SPWebPipeBind type. Note that to do the job you have to use an internal method of the Microsoft.SharePoint.SPElementProvider class but as it’s just a simple query I’m personally not concerned about the use of the reflection to make it work.
So with that, here’s my little Get-SPControlElement function:
And here’s a simple example demonstrating how to call the function (note that I put the code in a file named Get-SPControlElement.ps1 and then I dot source the file to load the function into memory – you could scope the function globally to avoid the need to dot source if you want):
This should work on both SharePoint 2010 and 2013 and I believe with some minor modifications you could make it work with 2007.
-Gary