PowerShell Module Management
Working with the latest technology is great. Not only you are the top notch for the leading technology but also you get job done with efficiency or impossible to do it in the past. However, there is a dark side especially working with the cloud. Things keep changing so the stuff you created today might not work next day.
I have built a bunch of PowerShell utilities based on AzureRM – the Azure Resource Manager module for accessing Azure resources from your local machine. I always have experience that things work perfectly but stop functioning after 2 months with various reasons – depreciate cmdlets, parameter removal, different routine introduced….etc (keep eyes on azure-powershell change log for every changes in the release). In order to maintain the functionality from my utilities, I end up spending quite a few time dealing with PowerShell module management. Therefore I would like to write this article to give you the fundamental how to deal with modules on your system so you can apply this technique for every PowerShell module during the troubleshoot.
Some basic concepts
- There is an environment variable called $env:PSModulePath. It is a string containing one or multiple paths where all of PowerShell modules reside. Starting with PowerShell 3.0, PowerShell implicitly import a module when one of the functions or cmdlets in the module is called by a user. (In PowerShell 2.0, you need to use the cmdlet "Import-Module" in order to use cmdlets inside that module). The PowerShell engine will search for the module using this path and load it dynamically once it is located.
- Starting with PowerShell version 5.0, it provides a bunch of cmdlets are introduced to communicate with PowerShell Gallery (PSGallery) site based on nuget feature. Your machine should have nuget feature or you can submit this cmdlet to install nuget: Install-PackageProvider -Name Nuget
- The module with different versions can coexist on your machine. However, the module with the latest version will be used if you don't specify -RequiredVersion while executing the cmdlet.
To manage PowerShell module, you need to open PowerShell console with administrative permission
List all installed versions on the machine
This is the cmdlet that you execute to verify the completed installation of PS module on your machine.
Cmdlet |
Description |
Screenshot |
Get-Module ` -ListAvailable [ModuleName] |
This will all installed versions of PSmodule.
|
Uninstall Module
Cmdlet |
Description |
Screenshot |
Uninstall-Module `-Name [ModuleName] |
This will uninstall the latest version of PSmodule. |
List all available versions on PSGallery
What if you want to install a specific version of PS module and you have no idea what versions are offered on PSGallery?
Cmdlet |
Description |
Screenshot |
Find-Module `-Name [ModuleName] |
This will find PSmodule on PSGallery and returned the last version. |
|
Find-Module `-Name AzureRM `-AllVersions |
This will return all available versions of PSmodule |
Install Module
Cmdlet |
Description |
Screenshot |
Install-Module `-Name [ModuleName] |
This will install the latest version of PSmodule. |
|
Install-Module `-Name [ModuleName] `-RequiredVersion 5.2.0 |
This will install the specified version 5.2.0 of PSmodule |
Here is my story from past experience dealing with AzureRM. After upgrading to version 5.4.1, I lost the capability switching to specific Azure subscription. After the lengthy process of troubleshooting, I decided to rollback to previous version in order to provide the functionality to get things going. Therefore I used cmdlets introduced above to rollback to version 5.1.1 in order to perform the function. I hope this will benefit you in the future when you deal with PowerShell module management.