I don't know where to report PowerCLI bugs ... btw Get-ErrorReport won't work for this bug.
There is a problem with PowerCLI 6.5 R1. When starting the x64 PowerCLI all PowerCLI modules cannot be loaded because this error: "Could not load file or assembly ‘log4net, Version=220.127.116.11, Culture=neutral, PublicKeyToken=692fbea5521e1304’ or one of its dependencies. The system cannot find the file specified." The x86 PowerCLI starts without any problems.
We've analyzed the problem. The problem is caused by a log4net assembly in the GAC (Global Assembly Cache).
PowerCLI ships a log4net assembly in the "Modules\VMware.VimAutomation.Sdk" folder. The log4net assembly is explicitly loaded by the PowerShell because it is in the RequiredAssemblies list of the VMware.VimAutomation.Sdk.psd1 module manifest (see VMware.VimAutomation.Sdk.psd1).
The already installed log4net assembly in the GAC and the log4net assembly shiped by PowerCli:
The PowerShell seems to raise an error when:
Regular "Any CPU" .NET applications behave differently. Assemblies in the GAC with a different processorArchitecture are ignored and not loaded.
BTW: Removing the assembly from the GAC isn't an option because this will break the software that installes log4net in the GAC: SAP Crystal Reports runtime engine for .NET Framework (32-bit), Version 18.104.22.1686
Steps to Reproduce
We can repoduce this problem:
see also comment of Waytraveler: https://blogs.vmware.com/PowerCLI/2016/11/new-release-powercli-6-5-r1.html
Can you please send the log4net.dll (SAP Crystal Reports) that is causing the problem? I'm unable to reproduce using locally built log4net.
Same issue when trying to load from script
Welcome to VMware PowerCLI!
Log in to a vCenter Server or ESX host: Connect-VIServer
To find out what commands are available, type: Get-VICommand
To show searchable help for all PowerCLI commands: Get-PowerCLIHelp
Once you've connected, display all virtual machines: Get-VM
If you need more help, visit the PowerCLI community: Get-PowerCLICommunity
Copyright (C) VMware, Inc. All rights reserved.
ERROR MSG:Unable to find type [VMware.VimAutomation.Sdk.Util10.ProductInfo].
At C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Scripts\Initialize-Pow
+ $powerCliFriendlyVersion = [VMware.VimAutomation.Sdk.Util10.ProductIn ...
+ CategoryInfo : InvalidOperation: (VMware.VimAutom...l10.Product
Info:TypeName) , RuntimeException
+ FullyQualifiedErrorId : TypeNotFound
Same issue on one of my machines when loading PowerCLI from the PowerShell Gallery...I can install the modules, but when I go to import them [Import-Module VMware.PowerCLI] it throws the log4net error.
I had no problem with this on another machine, but it has a lot less other software installed on it...if I had to guess, I'd say that Crystal Reports on the first machine may have the conflicting version (x86 vs 64) that is causing my problems, but that is purely a guess.
BTW, very pumped that PowerCLI is now available in the Gallery...
I found I had the same issue importing PowerCLI 6.5.2 on a disconnected network. However after going through some rabbit holes, copying the file (from a connected computer)Microsoft.PackageManagement.NuGetProvider.dll to C:\Program Files\PackageManagement\ProviderAssemblies\nuget\22.214.171.124\ fixed the issue. I wrote about it here: Powershell on Crack: Installing PowerCLI on a disconnected network
I even wrote an installer for PowerCLI 6.5.2
I dont know if this is the recommended solution, but for me it helped:
Create a folder
copy log4net.dll from
(or where ever you installed PowerCLI) into it.
After doing this,
get-module -list "VMware*" | import-module
I have tried on Windows 10, and succeeded.
I downloaded log4net that stitzeposted last February, created directory C:\Windows\assembly\GAC_64\log4net\126.96.36.199__692fbea5521e1304\ and copied file to that directory.
After that Windows PowerShell (x64) Import-Module VMware.PowerCLI worked.
Prior to this I could only load VMware.PowerCLI using Windows PowerShell (x86).
PowerCLI version is 11.0.0
I am on Windows 7 with PowerShell 5.1 installed. My resolution was changing "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noe -c " within the PowerCLI shortcut's "Target" to "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -noe -c ".
It appears to be an issue with 64 bit PowerShell which lives in "C:\Windows\System32\WindowsPowerShell\v1.0". 32 bit PowerShell lives in "C:\Windows\SysWOW64\WindowsPowerShell\v1.0" and seems to work without issue.