Hi Community,
I have been using PowerCli for a while and just finding myself struggling with something I used regularly in my previous company , but somehow it doesn`t work here on my new workstation
I want to access the properties of ExtensionData of a VM like
$vms= get-vm | Where {$_.ExtensionData.Config.Tools.ToolsUpgradePolicy -like "manual"}
but now it doesn`t work, once I tab (autofill) behind " | where {ExtensionData. " just
ToString(
Equals(
GetHashCode(
GetType(
is available.
If I access them like $vm.ExtensionData.Config ... it just works fine
What do I miss here?
Any suggestions?
thanks
Nico
I did some testing and it seems to be normal behaviour that, afaik, never has been different.
The issue is that ExtensionData at the moment you are editing that line is not a 'known' output object for the Intellisense engine.
Remember that ExtensionData is a property that appears on nearly all PCLI .NET objects.
With regular output types that are defined as the cmdlet attribute, the IntelliSense does work deeper than 1 level.
For example:
Get-VM | where{$_.Guest.
does show the correct properties.
For ExtensionData, the PCLI cmdlet itself needs to take extra action.
It first has to determine which kind of PCLI object it is looking at before it can determine what type of ExtensionData is required.The Intellisense engine does not have that logic.
I can't find a PowerShell, nor PowerCLI, version where Intellisense has worked in a pipeline and on the pipeline object ($_) beyond EXtensionData.
If you can find an example, I would love to learn about that.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
That looks to be an Intellisense problem.
Which PowerShell version ($PSVersionTable) and which IDE (ISE, VSC ...) are you using?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Hi LucD,
thanks for your reply.
$psversiontable gives me the following
PSVersion 5.1.18362.752
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.18362.752
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
and I use ISE where I encounter the same issue...
I did some testing and it seems to be normal behaviour that, afaik, never has been different.
The issue is that ExtensionData at the moment you are editing that line is not a 'known' output object for the Intellisense engine.
Remember that ExtensionData is a property that appears on nearly all PCLI .NET objects.
With regular output types that are defined as the cmdlet attribute, the IntelliSense does work deeper than 1 level.
For example:
Get-VM | where{$_.Guest.
does show the correct properties.
For ExtensionData, the PCLI cmdlet itself needs to take extra action.
It first has to determine which kind of PCLI object it is looking at before it can determine what type of ExtensionData is required.The Intellisense engine does not have that logic.
I can't find a PowerShell, nor PowerCLI, version where Intellisense has worked in a pipeline and on the pipeline object ($_) beyond EXtensionData.
If you can find an example, I would love to learn about that.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
To further clarify this aspect of Intellisense and ExtensionData.
When you have the pipeline object ($_) Intellisense relies on the OutputType of the cmdlet that placed the object in the pipeline.
(Get-Command -Name Get-VM).OutputType
But then the 'dynamic' nature of the ExtensionData property (see my previous explanation) comes into play.
No way for Intellisense to 'see' the properties beyond ExtensionData.
When you use $vm.ExtensionData then Intellisense just needs to look inside the ExtensionData object (that is already there) to present you with a list.
And I'm still convinced that this $_.ExtensionData Intellisense never worked as you seem to claim it did.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Hi Luc,
thanks for your effort and sharing your knowdledge.
While reading your answers I am second-guessing myself and you`re most propably right.
Unfortunately I am not able to reconstruct it exactly but yeah I probably just used copy paste for properties behind the pipe.
thanks a lot
Nico