Is it possible to enumerate all methods and properties that are available via Invoke() of an [ADSI] object?

Question

I am curious if someone can describe how to enumerate ADSI methods available via a bound instance as [ADSI]$instance.psbase.Invoke()?

Research has turned up "refer to the docs for the ADSI interface". but I am not particularly happy with that answer.

If I instantiate with:

[ADSI]$lhost_group="WinNT://./Administrators,group"

Then attempt:

@($lhost_group.psbase.Invoke("Members")) | foreach-object {$_.GetType().InvokeMember("Name", 'GetProperty', $null, $_, $null)}

Powershell will return the out of GetProperty("Name") for each object contained in the group.

How do I enumerate all of the available methods and properties that would be available via any given ADSI interface?

This answer from Shay Levy is another example of syntax where [ADSI]$_.GetTypes().InvokeMember() and [ADSI]$_.psbase.Invoke() are used.

Answer 1

The answer is 'no' and it is unlikely to change. I share your unhappiness with that answer, but I can provide some technical background to support and explain it.

The core problem is that the native-code ADSI objects must implement the COM interface IDispatch [which allows late-bound methods to be called], but they don't necessarily implement ITypeInfo [which allows reflection-like behavior]. In PowerShell, a COM object that implements IDispatch but not ITypeInfo results in odd set of restrictions, which is what you are noticing.

The WinNT ADSI provider is at least 15 years old, and it was never a strong feature. It was a placeholder written before Active Directory shipped (way before the CLR or PowerShell.) Back then, 'scripting' at Microsoft meant early versions of VBScript, with with some support for JScript, both of which relied on IDispatch and never used ITypeInfo.

This was a topic of discussion early in PowerShell's life, when one of the PowerShell team member said:

14 Jul 2006

... The PowerShell can't show the methods of COM objects if the ITypeInfo interface is not provided. This will be fixed soon. The workaround is to use Type.InvokeMethod().

There have been improvements in PowerShell's support of COM objects, but a complete fix never materialized. I think the team member may have over-promised what is technically possible. This may have confused people. I asked a developer lead friend of mine on the team about this a couple of years ago; he was clearly familiar with the issue and indicated that the use-case wasn't a high-priority and mentioned the workaround too.

The PowerShell team has been shipping impressive features and some bug-fixes, but frankly I don't think this issue will ever make the bug bar.

Answer 2

Not exactly sure if this answers your question, but what about the following?

$lhost_group.getType().DeclaredMembers | where { $_.MemberType -eq "Method" -or $_.MemberType -eq "Property" }