Concerns using Update-Module causing multiple versions of the same module

[MaximoTrinidad]

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)

1. Make sure Azure Module version 5.0.1 is already installed.
2. Proceed to execute Update-Module -Name AzureRM

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

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17046.1000
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17046.1000
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

> Get-Module
AzureRM

> Get-Module -ListAvailable PowerShellGet,PackageManagement

    Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     1.1.7.0    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-P...
Binary     1.0.0.1    PackageManagement                   {Find-Package, Get-Package, Get-PackageProvider, Get-P...
Script     1.5.0.0    PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Modu...
Script     1.0.0.1    PowerShellGet                       {Install-Module, Find-Module, Save-Module, Update-Modu...

> Get-PackageProvider

Name                     Version          DynamicOptions
----                     -------          --------------
msi                      3.0.0.0          AdditionalArguments
msu                      3.0.0.0
NuGet                    2.8.5.210        Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag...
PowerShellGet            1.6.0.0          PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, ...
Programs                 3.0.0.0          IncludeWindowsInstaller, IncludeSystemComponent


>Get-PackageProvider -ListAvailable

Name                     Version          DynamicOptions
----                     -------          --------------
msi                      3.0.0.0          AdditionalArguments
msu                      3.0.0.0
nuget                    2.8.5.208
NuGet                    2.8.5.210        Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterO...
PowerShellGet            1.5.0.0          PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherChe...
PowerShellGet            1.0.0.1
Programs                 3.0.0.0          IncludeWindowsInstaller, IncludeSystemComponent

Sorry! During my cleanup update I ended up removing all versions
Below is a print screen of what was happening.

[Jaykul]

It would be really nice to have a switch to say something like -RemoveOldVersions

[MaximoTrinidad]

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.
:)

[MaximoTrinidad]

@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.

[Jaykul]

Yeah, with shared dependencies it gets really messy...