When in Doubt, Reflect.

Reflector-providerIn the ongoing saga of my Newsgator Powershell provider (well, ongoing to me if not to you), I think there’s finally been a break in the case. As are so many other things, it’s all thanks to Lutz Roeder’s Reflector. I don’t think I can say enough about the usefulness of this tool.

In the absence of documentation or a good (complete) sample online, I’ve been hesitating to invest the time it would take to map out the required implementation for a Powershell provider. Take, for example, the following method signature (which is all I have to go on):

protected override void GetChildNames(string path, ReturnContainers returnContainers)
{
}

On this information alone, how do I know what format to expect “path” in? What does the ReturnContainers enum imply? (That’s maybe more self-explanatory.) You see how it can quickly take a fairly long time to investigate it all. Enter Reflector. I used Reflector to pull up the built-in Registry provider that belongs to the Microsoft.Powershell.Commands namespace, and is found in the System.Management.Automation assembly. In no time I had before me a great (well, maybe just good since the code still lacks symbols) example of a similar provider implementation!

Awesome.

Update
Slightly less than awesome: the RegistryProvider makes use of some internal classes that would make my life easier… <sigh>. Still a great example though.

This entry was posted on Sunday, June 18th, 2006 at 2:57 pm and is filed under powershell, programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “When in Doubt, Reflect.”

  1. aaron Says:
    August 22nd, 2007 at 11:29 pm

    I mostly had in mind the PSTraceSource (and related) classes. I was excited to see built-in tracing that I could take advantage of, especially since at that time I didn’t know much about how things worked–in terms of both what individual methods were intended to do, and what the logical interactions were between methods.

    I could’ve implemented my own tracing, but it seemed like such a waste when all that functionality already existed!

    Thanks!

  2. Anonymous Says:
    August 22nd, 2007 at 11:29 pm

    Aaron – which classes do you want us to make public?

    PSMDTAG:FAQ: How can I find out what PowerShell is REALLY doing? Answer: Reflector

    PSMDTAG:Internal: How can I find out what PowerShell is REALLY doing? Answer: Reflector

    Jeffrey Snover [MSFT]
    Windows PowerShell/Aspen Architect
    Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
    Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Reply