As you are all aware of the upcoming PowerShell Core, and the impact it will bring in our cross-platform infrastructure. For now, both Windows Powershell and Powershell Core will co-exist side by side. Also, our Powershell skill sets will still be on a high degree of demand in the workplace. This is not going to slow down.
So, let’s create some awareness when installing Powershell modules. Now, we’ve seen a raise of *core modules which are targeted to be use with PowerShell Core for the purpose of installing them in either Windows and/or non-Windows environments. But at the same time, and I have experience, installing different versions of the same module in Windows PowerShell.
Let’s take for example AzureRM modules.
Cloud Module Balance
Let me say you will possibly experience this in the following situation:
1. If you’re install Visual Studio with the Azure SDK
2. If you’re a Developer which are trying to keep up with the latest module but forget to remove the old ones.
3. Also, installing modules from different sources.
Which sources are currently available for installing Azure modules?
(Just to name a few)
1. PowerShell Gallery
2. Azure Download
3. Azure SDK’s (VS Studio installation or standalone)
So, having multiple versions of the same modules may lead to issues such as: deprecated commands, invalid parameters/paramterset, and all leading to broken automation scripts.
It’s been suggested to use the PowerShell Gallery to get the Azure PowerShell Modules. But, always to the proper search for the latest version.
Using Powershell Gallery as the main repository for grabbing PowerShell modules, you can query for the modules before installing them:
1. Set the main repository to be “PowerShell Gallery”:
[sourcecode=”powershell”]
## – Set PowerShell Gallery Repo:
Set-PSRepository `
-Name “PSGallery” `
-InstallationPolicy Trusted;
[/sourcecode]
2. Find the modules you want to install: (In this case, “AzureRM”)
[sourcecode=”powershell”]
## – Find Module(s) in PowerShell Gallery for Windows PowerShell:
Find-Module -Name AzureRM
## – Find Module(s) in PowerShell Gallery for PowerShell Core:
Find-Module -Name AzureRM.Netcore
[/sourcecode]
Now, you can proceed to install the module:
1. Proceed to get the module from PowerShell *Gallery:
[sourcecode=”powershell”]
## – Get/install Module(s) from PowerShell Gallery:
Install-Module -Name AzureRM `
-Repository “PSGallery”;
[/sourcecode]
*Note: Installing AzureRM.Netcore in Linux, you need to use ‘sudo pwsh’.
2. List the installed module(s):(Windows and Linux)
[sourcecode=”powershell”]
## – List of installed AzureRM modules:
Get-Module -ListAvailable AzureRM* `
| Select name, version, path;
[/sourcecode]
At this point, you can start building scripts.
Working with PowerShell Gallery
The following series of commands will get you started working with PowerShell Modules.
1. List all installed modules in system and can help to spot duplicates:
[sourcecode=”powershell”]
## – List of installed all PowerShell modules:
Get-Module -ListAvailable `
| Select Name, Version, Path `
| Sort-Object Name, Version;
[/sourcecode]
2. List installed modules locations in the PSModulePath variable:
[sourcecode=”powershell”]
## – List installed modules locations
$env:PSModulePath.split(‘;’);
[/sourcecode]
These two commands will give you the necessary information to identify and locate all *”installed” modules in yours system.
*Note: This will not include manually custom modules as the are not install thru PowerShell Gallery, or outside of the standard PowerShell Module folders.
Managing your Modules
In order to prevent cluttering your system with modules you may not use, then its time to do some module updates and/or cleanup.
From Github post “…Moving forward, we recommend using the PowerShell Gallery to get the Azure PowerShell modules. We are looking to push out updates to AzureRM more often since we no longer need to update every module we ship in AzureRM, which will speed up the install/update. …”
Taking advantage of PowerShell Gallery commands, we can update our installed modules:
[sourcecode=”powershell”]
# Updating the modules in AzureRM
Update-Module -Name AzureRM
[/sourcecode]
This step should prevent us installing multiple versions of the same module. (Update) – But, I discovered that this will cause a duplicate module (different versions) after the Update-Module is completed.
What about module(s) cleanup? The following one-liner can be use to cleanup/remove module(s) that install from the PowerShell Gallery. In the case of cleaning up all AzureRM modules, the following command should remove all *modules:
[sourcecode=”powershell”]
## – This will remove all AzureRM submodules “AzureRM.*:
Get-Module -ListAvailable `
| where-Object {$_.Name -like “AzureRM*”} `
| Uninstall-Module;
## – This will remove the AzureRM main module:
Get-Module -ListAvailable `
| where-Object {$_.Name -like “AzureRM”} `
| Uninstall-Module;
[/sourcecode]
*Note: This command will work as long as you have use the Install-Module to grab the modules from PowerShell Gallery. And, it will take some time to complete.
This way you can start clean and reinstall the modules!
Then, restart your PowerShell session, and use the following command to Get-Module again to list all existing modules.
Side-By-Side PowerShell Modules
As, the PowerShell Gallery has become the main repository for PowerShell Module. The Microsoft PowerShell Team has provided a special module to allow Windows Modules to work side-by-side with PowerShell Core:
https://www.powershellgallery.com/packages/windowspsmodulepath/1.0.0
Github post: “… This is currently by-design as we deliberately wanted Windows PowerShell and PSCore6 to work side-by-side with predictability. …”
This will assist in identifying what else need to be done PowerShell Core. Just give it a try!
If you find issues with Windows Modules in PowerShell Core, then let the Microsoft PowerShell Team know in Github:
https://github.com/PowerShell/PowerShell
Conclusion
Managing modules when using PowerShell Gallery still is a manual process but easy to use, and even better if you build your own solution. I some instances you may decide to us the old delete or move command to get rid of unwanted modules.
Just take the necessary precautions, and remember, that you could install it back if needed.