Open MaximoTrinidad opened 6 years ago
It would be really nice to have a switch to say something like -RemoveOldVersions
I have address this issue ( to @JKeithB ) recently at the MVP Summit. But this is by-design, and special to protect the anyone of removing Modules by mistake.
And, specially, using the Update-Module, thinking that will in fact update to the latest version but in reality keeps the previous version installed.
This happens with, not only AzureRm modules, but with any other ones downloaded from the PowerShell Gallery.
I had to create a script code, in this case to identity the AzureRM installed Module(s), and then I can uninstalled it:
Import-Module PowerShellGet
$Modules = Get-Module -ListAvailable AzureRM* `
| where-object{ $_.name -notmatch ".NetCore" } `
| Select-Object Name, Version;
foreach ($Module in $Modules.Name)
{
Write-Host "Removing module: $($Module)" -ForegroundColor Yellow;
Uninstall-Module -Name $Module -Force;
};
They will probably come up with a resolution to help us in this scenario. :)
@whiggs,
BTW using the remove-module modulename will clear the lock condition. :)
We do have on our backlog adding an additional optional parameter to uninstall previous versions of a module when you do an update.
This is by design, because PowerShellGet was added when PowerShell added support for side-by-side versions of modules. With side-by-side module versions, we created the issue wherein a developer MAY take a dependency on a specific version of another module and still install the latest copy for use by other things. There are, as it turns out, many modules that take advantage of this feature, starting with some of the Azure modules. As a result, if you remove a module version when updating to the latest copy, you can break some other module in a way that is extremely difficult to identify programmatically, and even more difficult to troubleshoot once it happens.
The intent in the future is to provide a flag (something like "-RemovePreviousVersion"), which will give the user the choice.
Yeah, with shared dependencies it gets really messy...
I've been experiencing issues running script due to having multiple versions of the same module installed in my system.
I good example is with the AzureRM modules. Then, I just use the Update-Module cmdlet to update (is my understanding) AzureRM module from version 5.0.1 to the latest version 5.1.1
Expected Behavior
To see AzureRM module upgraded from version 5.0.1 to the latest version 5.1.1.
Current Behavior
It will create multiple AzureRM module: version 5.0.1 and 5.1.1
Possible Solution
Steps to Reproduce (for bugs)
Context
Having multiple versions of the same module has cause issue executing scripts having obsolete/deprecated cmdlets and/or invalid parameterset.
Your Environment
Windows 10 Insider Build 17046
Sorry! During my cleanup update I ended up removing all versions Below is a print screen of what was happening.