Hello everyone,
I'm building an internal PowerShell module repository in my company and I'm frustrated about PowerCLI.
Let me explain why...
PowerCLI is great but PowerCLI is still a PowerShell snap-in. Snap-ins are deprecated since PowerShell 2.0; why VMWare still continues to ship PowerCLI as a snap-in?
Modules are great because they just need to be copyed and pasted into the user's (or computer's) module directory and that's it, it is then directly usable via Import-Module. Whereas a snapin needs to be installed with administrative rights locally (as opposed to modules).
Furthermore PowerCLI being a snapin it doesn't fit into my internal modules' repository.
To the PowerCLI Team : can you please consider shipping the next version of PowerCLI as a module? Or at least Blog about how to transform your snapin into a binary module?
Thanks a lot in advance,
Arnaud Petitjean
PowerShell MVP
I fully agree with you, and I'm pretty sure the PowerCLI people know about this.
In the meantime you can simulate a PowerCLI module quite easily like this
$module = Get-PSSnapin -Name VMware.VimAutomation.Core
Remove-PSSnapin VMware.VimAutomation.Core
Import-Module $module.ModuleName
If you now do
Get-Module -Name VMware*
it will look as if you have a PowerCLI module
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Thanks Luc for your answer, but it only seem to work...
It will work on your local machine as a charm, but if you copy the snapin's directory on any machine (not installing it) like you would do it with a module, it does not work. It seems to work but it does not.
I'm able to do this :
PS > Import-Module .\VMware.VimAutomation.ViCore.Cmdlets.dll -verbose
The "module" seems to load normally (and I was happy). But as soon as you try to use any command, you get errors.
Example:
PS > Connect-VIServer myServer
Connect-VIServer : Impossible to load the assembly 'VMware.VimAutomation.Logging.SoapInterceptor, Version=4.1.1.0,...
Can you try please?
Arnaud
Indeed that is a limitation, there is of course no module manifest that indicates what DLLs are required.
You could solve that by writing your own manifest and use the RequiredAssemblies section to specify the DLLs.
But I admit, that is quite cumbersome.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Btw did you already see the post called PowerCLI 5.1 and the future from Alan on the PowerCLI Blog?
In the comments I also raised the module question.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Thanks, fat-fingered Ctrl-V I guess :smileyblush:
I corrected the link.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
This is certainly something that is high on our list of things to look at in future versions, at the moment we have several snapins in PowerCLI which make up the PowerCLI product so we will need to work together with all the teams who produce these individual snapins to ensure these are now modules. Believe me we are working on it.