How to expose functionality to PowerShell from within your application

Question

I was listening to the podcast about PowerShell 2.0 that Scott Hanselman did. In that episode, they talked about the possibilities to extend your application to expose functiona

Answer 1

Here's a good book on this side of powershell (which doesn't get much coverage in most books).

Professional Poweshell Programming

Using this book (and some trips to msdn), I was able to have a custom powershell host up and runnning in a day. A few days later, I had custom cmdlets that interact with the gui (to build treeviews, grids, diagrams, menus, etc.)

Answer 2

There are a couple of levels of PowerShell support, and not many people explain this well.

1. .NET classes. Yes, anything with a .NET API can be accessed by PowerShell without you doing anything extra! But, you don't get quite all of the extra PowerShell features. The least amount of work.
2. A PowerShell module with cmdlets, scripts, and/or functions. This will require writing some PowerShell specific code to wrap around your existing API. If you go this route, you should sit down and learn the best practices for PowerShell design and think out your PowerShell support. This is more work required to do it right.
3. PowerShell providers. Providers are a special case, not everything should have a provider. You need to really consider whether your information really makes sense in a file system view.

This doesn't apply to your question, but I'll add it for completeness.

4. Hosted PowerShell. You can host PowerShell code in your app, or access PowerShell functionality from your app. This makes sense in some situations, but is also a specialized case of PowerShell support.

Answer 3

There are multiple ways to leverage PowerShell in a custom application. The beauty of the PowerShell Automation engine is that you don't have to deal with handling parameters, formatting output, and bunch of other PITA things that you would have to handle yourself. To throw an object down the pipeline in PowerShell, you override the ProcessRecord Method and call WriteObject

protected override void ProcessRecord()
{
  // Get the current processes
  Process[] processes = Process.GetProcesses();

  // Write the processes to the pipeline making them available
  // to the next cmdlet. The second parameter of this call tells 
  // PowerShell to enumerate the array, and send one process at a 
  // time to the pipeline.
  WriteObject(processes, true);
}

You can write Cmdlets that allow an admin to automate the server side of an application. Cmdlets are always task based units of functionality with verb-noun naming convention. For example, Get-Process, or Restart-Service. Cmdlets do one thing and do it very well. There is all kinds of incredible power that comes with combining cmdlets together.

Also, if your app has some sort of data store, its also possible to write a provider which would allow someone to browse and/or manage the data store using cmds like cd (set-location) and md (new-item). A provider is what the PS team wrote so you can cd into the registry with cd hklm: or the certificate store with cd cert:

You can also host PowerShell itself in your application.

There is some good information on all three of these options on MSDN here

Considering the interest in providers, here are some examples on how to create a PowerShell Provider.

There has been a few discussions about design and using a set of cmdlets or to expose something with a Provider. When you implement a provider, you also get a few cmdlets, such as Get-item, New-item, Get-Location, Set-Location. However, I have found that having some cmdlets for specific tasks in addition to a provider can be very helpful.