Combine PowerShell Modules to Avoid Writing Scripts

Combine PowerShell Modules to Avoid Writing Scripts

  • Comments 1
  • Likes

Summary: Learn how to combine Windows PowerShell modules to save time and reduce scripting overhead.

 

Microsoft Scripting Guy Ed Wilson here. One of the cool things about Windows PowerShell modules is that they are easy to share. In addition, because the code is packaged as a module, one automatically knows what to do with the module, and how to use the code. If someone hands me a script, I have to read through it to figure out how to use it. Of course, I have to read through the code of a module before I read it, but that is simply a safety measure to ensure that I am not loading nefarious code into my computer.

One of the things that immediately begins to bug me when I build a new computer is that Windows PowerShell is hidden in the Accessories menu. I mean it takes five clicks of the mouse, and one scroll of the mouse wheel to launch either Windows PowerShell or Windows PowerShell ISE. If I want both of them running, which I normally do, it takes 10 clicks of the mouse and two scrolls of the mouse wheel. Because I often close and open Windows PowerShell during the course of the day, it does not take too much before I have literally made several hundred mouse clicks and nearly a hundred mouse wheel scrolls. Not only does that waste a lot of time, but that also begins to take its toll on the wrist, elbow, and even shoulder.

I know that I wrote a script a long time ago to pin an application to the taskbar, but for some reason I am unable to find it. I then remembered a module that was created by Jan Egil Ring. Jan writes a blog and has some pretty cool articles. The PinApplications.psm1 module will pin and unpin applications from both the taskbar and from the Start menu. Luckily, Jan uploaded the module to the Scripting Guys Script Repository, so it is easy to locate. All I had to do was go to the page displaying the module, click Copy Code, and paste the module into my Windows PowerShell ISE. I like to save my scripts and modules in a scripts folder. This folder becomes my main script repository, and the files in here are my backup files. After I have saved the PinApplications.psm1 module file in its own folder, I use my Copy-Modules.ps1 script to install the module in my personal modules directory.

One of the things that I have not had a chance to do is to figure out how to create my own libraries in Windows 7. I have spent a bit of time browsing MSDN, and did find an article that discussed working with the API. Unfortunately, there are no .NET Framework classes to do this. While I can use the Add-Type cmdlet to work with native code, the results are not very pretty. (See these Hey, Scripting Guy! Blog posts for some excellent examples of this type of scripting.)

Anyway, luckily I ran across the Windows7Library for PowerShell project on Codeplex.  (Make sure you get the updated version of the module. Ragnar updated the module to version .5 based upon some feedback I had given him while I was writing this article.) This project, written by Ragnar Harper, is discussed on Ragnar’s blog. One limitation of my Copy-Modules.ps1 script, is that it only looks for modules and for manifest files. It does not look for *.xml, *.dll, or *.exe files. I did this on purpose because I wanted an easy installer for “script modules” not for more complex types of module projects. I figured that if I created a module project that relied on external *.dll’s or *.exe files, I would create a Windows Installer project to do that. As seen in the following figure, Ragnar’s Windows7Library module uses several different file types; this is because he relied upon a couple of other projects to simplify the creation of his module.

Image of Ragnar's module using different file types

 

This does not mean that I cannot use my Copy-Modules.ps1 script to install the Windows7Library module. But it does mean that I will need to copy the remaining files into the folder once I run the script.

AfterI have the two modules installed, I can write a quick script to pin my applications to the taskbar and to create my custom libraries.

There are four default libraries created when Windows 7 is installed. These are stored in the profile. The four default libraries appear in the following figure.

Image of default libraries in Windows 7

My complete SetLibraryAndTaskBar.ps1 script is not too complicated. It includes two Import-Module statements, and then calls the Set-PinnedApplication function to add Windows PowerShell and the Windows PowerShell ISE to my taskbar. It then creates a library, and adds a folder to the library. In reality, I would not need to really create this “script” except that these are things I generally do to all of my workstations, and it saves a bit of typing.

Import-Module PinnedApplicationsModule

Import-Module Windows7Library

 

Set-PinnedApplication -Action PinToTaskbar -FilePath $PSHOME\powershell.exe

Set-PinnedApplication -Action PinToTaskbar -FilePath $PSHOME\powershell_ise.exe

Add-Library -LibraryName "ScriptingGuys_2011"

Add-LibraryFolder -libraryName "ScriptingGuys_2011" -folderPath E:\data\ScriptingGuys\2011

 

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Looks great, Ed!

    We can use Modules as we did already before with Active-X Components!

    Now we may add them to our portfolio and have an even broader repertoire of "tools"!

    It is good to use well known, tested and performant functions, that we may not want to

    write on our own. But you should remember that it might be difficult to presume that those

    components are available everywhere and if they are, they might have different versions!

    Hopefully we'll end not up in a state like "DLL-Hell".

    Modules will have to be well documented and maintained by their authors!!!

    Klaus