Posted by: Bcournoyer
when relevant content is
added and updated.
During our conversation, I asked him for his take on some of version 2’s improvements, expecting to hear mostly about the new remoting functionality. While he certainly thought remoting would have a huge impact, it was another feature called Powershell modules that he really wanted to talk about.
The basic idea behind modules is that they offer better control over which PowerShell functions get exported, which Hill noted should be very useful to administrators with development experience. Rather than try and break it down myself, I thought I’d just share how he explained the feature, in his own words:
Kind of what Microsoft is shooting for with the idea behind modules is what they have for Perl … I think it’s called CPAN … where you can download all sorts of different packages for doing different things.
With PowerShell 1.0, essentially all you could pretty much get from folks was really two things. First, a compiled snap-in that various vendors would make available that would give you compiled functionality, but that takes fairly sophisticated developers that know how to write a C# program against .NET.
Then the other thing you could do was write a script file. A lot of admins could write script files, but script files are a little bit limited in that they either are written to be executed as is, or they are meant to be imported, in which case everything in the script file in terms of functions gets imported into your session, and everything outside the function executes and runs. So that had the unfortunate side-effect that any variables you declare sort of pollutes your global session state. And you may have functions that are meant to be more internal-only, but the way the scripts get what they call ‘dotsourced’ is that everything gets exposed in your global session state.
So what modules allow you to do is have some control over what gets exported. So by default, none of the variables get exported; they are treated as private. And by default all the functions get exported; they are treated as public. But you can say ‘I don’t want to export this function or that function, I only want to export these two functions here.’ Everything else is essentially private implementation details, and what’s more is that the person who consumes this has the ability to not only import it using the import module cmdlet, but they can also remove it when they are done.
That’s something you couldn’t really do effectively with scripts before this. You would dot into your environment because once they were there, you’d have all these extra functions and variables lying around. So it’s a much nicer way to package things up in a more encapsulated way.
And the installation is really just an XCOPY experience. There’s a well-known directory that folks have under their user profile. They have documents and Windows PowerShell modules, and the idea is that the various different modules they get from people, they can just XCOPY to that location, and then they can just import whatever the module happens to be.
So the idea there is that they can allow administrators who have development experience to write these reusable modules that do all sorts of different, useful things, and then folks can easily go grab them, XPCOY them to this location, import them, use them, and when they are done, they can remove them.
For more on Windows PowerShell 2.0, visit SearchWindowsServer.com.