Enthusiast
Enthusiast

Powershell cmdlet conflict with latest powercli

Jump to solution

I've got the latest fast-track version of windows 10 (build 180706) and I'm trying to install powercli from the Powershell Gallery (PowerShell Gallery | VMware.PowerCLI 10.1.1.8827524 ).

When I do this I get errors about conflicting cmdlets:

PS C:\WINDOWS\system32> Install-Module -Name VMware.PowerCLI

Untrusted repository

You are installing the modules from an untrusted repository. If you trust this repository, change its InstallationPolicy value by running

the Set-PSRepository cmdlet. Are you sure you want to install the modules from 'PSGallery'?

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): Y

PackageManagement\Install-Package : The following commands are already available on this

system:'Export-VM,Get-VM,Get-VMHost,Move-VM,New-VM,Remove-VM,Restart-VM,Set-VM,Set-VMHost,Start-VM,Stop-VM,Suspend-VM'. This module

'VMware.VimAutomation.Core' may override the existing commands. If you still want to install this module 'VMware.VimAutomation.Core', use

-AllowClobber parameter.

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 char:21

+ ...          $null = PackageManagement\Install-Package @PSBoundParameters

+                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception

    + FullyQualifiedErrorId : CommandAlreadyAvailable,Validate-ModuleCommandAlreadyAvailable,Microsoft.PowerShell.PackageManagement.Cmdlet

   s.InstallPackage

PS C:\WINDOWS\system32>

I know I can get around this with the -AllowClobber parameter but that's a really kludgy way to do this and will most likely cause problems in a mixed Hyper-V/Vmware environment.

1 Solution

Accepted Solutions
Leadership
Leadership

Not sure what the question is in here?

So the developers of the PowerCLI and Hyper-V module have chosen some conflicting names, like Get-VM.

Seen the age of both modules, I don't think either side will change the name of any of these conflicting cmdlets.

But PowerShell has foreseen these potential conflicts very early. There are in fact a couple of ways to avoid confusion.

Use the fully qualified module name to avoid the name collision

VMware.VimAutomation.Core\Get-VM

Or use a module prefix of your own liking

Import-Module -Name VMware.VimAutomation.Core -Prefix PCLI

Get-PCLIVM


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

View solution in original post

13 Replies
Leadership
Leadership

Not sure what the question is in here?

So the developers of the PowerCLI and Hyper-V module have chosen some conflicting names, like Get-VM.

Seen the age of both modules, I don't think either side will change the name of any of these conflicting cmdlets.

But PowerShell has foreseen these potential conflicts very early. There are in fact a couple of ways to avoid confusion.

Use the fully qualified module name to avoid the name collision

VMware.VimAutomation.Core\Get-VM

Or use a module prefix of your own liking

Import-Module -Name VMware.VimAutomation.Core -Prefix PCLI

Get-PCLIVM


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

View solution in original post

Enthusiast
Enthusiast

The question is "how do I install it without having to use a kludgy workaround" - previously, installing from the MSI wasn't an issue. Installing from the PSGallery is an issue.

and it's also a matter of highlighting that the install instructions on the powershell gallery are not complete, this really needs to be highlighted.

0 Kudos
Enthusiast
Enthusiast

Just to be sure that this is a conflict, I'll test this out later on with a completely clean install.

0 Kudos
Leadership
Leadership

This has nothing to do with the MSI vs Gallery installation!

The exact same problem was present there as well, the MSI based installation just didn't tell you.

You just encountered the issue later (as many threads in here have proven in the past).

The installation instructions obviously assume a clean (i.e. empty) environment, where the issue can't happen.

Also note that the issue pops up with the one that has the duplicates.

So if you install the Hyper-V module after the PowerCLI modules, the NoClobber switch will be needed for the Hyper-V module.

I'm really not sure what you want to achieve with this thread?

PowerShell has foreseen the potential issue and offers multiple ways to solve the conflict.
And since all these modules are now coming from the Gallery, it's much easier for Install-Module to warn the user of the potential conflict.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Enthusiast
Enthusiast

This has nothing to do with the MSI vs Gallery installation!

Except that, as you've said, the MSI version hides the issue which while far from ideal still means that there is a change in behaviour from one install method to another.

The installation instructions obviously assume a clean (i.e. empty) environment, where the issue can't happen.

I might be misunderstanding this but wouldn't the conflicting commands be built into the base powershell install that comes with Windows 10?

I'm really not sure what you want to achieve with this thread?

Just highlighting something that I saw as a problem because when I install from the gallery I get errors. It might be handy to have something on the gallery install page that says "Hey, you might see this issue, if you do, this is why you see it".

And since all these modules are now coming from the Gallery, it's much easier for Install-Module to warn the user of the potential conflict.

Not having duplicate cmdlets would also be a nicer, neater, cleaner option.

Leadership
Leadership

Looks like you want to make a point that is not really a point.

At least not for me.

The title of your thread is incorrect, the conflicting cmdlets (with Hyper-V) have been there since 2011.


I personally prefer to be warned of potential conflicts, instead of discovering them on the go.
But I agree, that is a personal choice. To each his own.

The Hyper-V module was included for the first time in Windows 2008 R2 in 2011.

Since PowerCLI, and the Get-VM cmdlet, officially saw the light in 2008, your logic should direct you to talk with Microsoft.
Since PowerShell is open, you can easily create an Issue on the PowerShell repo for that.

When multiple companies produce PowerShell modules, and since there is a limited set of approved verbs, it seems unavoidable that conflicts will arise.

Luckily the PowerShell Team foresaw this, and provided some workarounds (see my earlier reply).

The MSI you seem to like is only usable in a Windows environment.
The introduction of the PowerShell Gallery, made distribution of modules portable.

Which was a requirement to allow PowerShell v6 to go multi-platform.

If you want to stick with a MSI, there are tools and procedures to package modules in an MSI file.

See for example From script to server – Deploying solutions with PrimalScript 2014 (Part 2)


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Enthusiast
Enthusiast

The nuget gallery works fine and is certainly an easier way of getting updates over the traditional MSI approach and that's great, more information about conflicts is always handy as well. Once again, thank you for your help here it is appreciated.

0 Kudos
Leadership
Leadership

You're welcome :smileycool:


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
Contributor
Contributor

LucD You are technically correct, but you don't have to be a jerk about it. It's the exact same question I had coming into it fairly blind, being both pretty new to powershell and the current state of the vmware ecosystem.

It would be entirely reasonable, helpful, and more efficient if the docs simply stated something like: "This has a known namespace collision with the HyperV provider, the work-around/solution is to use the -prefix command when importing the module(s), (Link to Official MS Docs), here is an example command:

Leadership
Leadership

Thanks for the nice title you gave me there :smileycool:
According to the Urban Dictionary you mean I'm "An idiot or stupid person. An insensitive, selfish, ignorant, cocky person who is inconsiderate and does stupid things."

I'm not sure why you think I deserve that, I gave the explanation about cmdlet conflicts early on in the tread, including the possible solutions provided by PowerShell.

And I also gave the advantages the PSGallery brings vs MSI files, mainly multi-platform support.


Btw, you could also ask MSFT to update their docs, the PowerCLI Get-VM cmdlet was there before the Hyper-V version.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
Enthusiast
Enthusiast

can't the big boys like vmware and Microsoft play nicer? Even in posh7 they used these names, even though the opensource community controls this.

0 Kudos
Enthusiast
Enthusiast

"Since PowerShell is open, you can easily create an Issue on the PowerShell repo for that."

That is the answer and I will do so today if it has not already been done.

Contributor
Contributor

The question is simply: "What do I do"? I've run into the same issue, and I'm here because I had to search google. Typing "-allowclobber" doesn't sound like a great thing to do. "Clobber" is not a nice friendly word like "conflict", it implies traumatic impact with brute force: they clobbered him with a mace 'til his skull was thoroughly crushed.

Your two, helpful, workarounds presume that one succeeds in installing the module somehow, and that's the ask. Once that's done, then I can proceed to use an explicit path or prefix.

0 Kudos