While working on a project I recently created a web part where I could specify a set of criteria and it would display hyperlinks to all site collections that matched. The nice thing about this web part is that you get a list of site collections that match a wide variety of criteria. Some of the criteria that could be specified was the template type, URL wildcard matching, web application, etc. Any matching site collections would be placed into a Dictionary<string, string> object containing the site collection’s title and URL. The web part would then render the contents of the Dictionary object into a list of hyperlinks on the page.

Later in the project I was developing a PowerShell management script to deactivate/activate features on a batch of site collections and again wanted to get a subset of site collections that matched a very specific set of criteria. Well, I knew that I already had the logic contained in a web part. My first thought was to take the same logic and rewrite it in PowerShell. Then I thought, wait, can’t I just leverage the code already written?

Luckily, I had a public method in the web part where the criteria parameters could be passed and a Dictionary<string, string> object was returned with any matching results.

public Dictionary<string, string> GetData(SPWebApplication currentWebApp, bool currentOnly, string templateType, string mask)

Now, I don’t want to get into a philosophical debate here. Yes, I could have extracted the query logic from the web part and put it into its own class and referenced that class in the web part and the PowerShell script, but hey – don’t fix what isn’t broke.

So, from within the PowerShell script I loaded the assembly that contained the web part and created an instance of the web part and called the GetData method to get a collection of site collections that I wanted to continue to work with.

Again, I’m not saying whether this is right or wrong, just an interesting way to leverage existing functionality from PowerShell.