scripts - wikipedia windows powershell

¿Es posible enumerar todos los métodos y propiedades que están disponibles a través de Invoke() de un objeto[ADSI]?

Question

Tengo curiosidad si alguien puede describir cómo enumerar los métodos ADSI disponibles a través de una instancia vinculada como [ADSI]$instance.psbase.Invoke() ?

La investigación ha aparecido "consulte los documentos para la interfaz ADSI" . pero no estoy particularmente feliz con esa respuesta.

Si instanciamos con:

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

Luego intenta:

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

Powershell devolverá GetProperty("Name") para cada objeto contenido en el grupo.

¿Cómo enumero todos los métodos y propiedades disponibles que estarían disponibles a través de cualquier interfaz ADSI dada?

Esta respuesta de Shay Levy es otro ejemplo de sintaxis donde se [ADSI]$_.GetTypes().InvokeMember() y [ADSI]$_.psbase.Invoke() .

Answer 1

No estoy seguro si esto responde su pregunta, pero ¿qué pasa con lo siguiente?

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

Answer 2

La respuesta es ''no'' y es poco probable que cambie. Comparto tu infelicidad con esa respuesta, pero puedo proporcionar algunos antecedentes técnicos para apoyar y explicarlo.

El problema principal es que los objetos ADSI de código nativo deben implementar la interfaz COM IDispatch [que permite llamar a los métodos de destino tardío], pero no necesariamente implementan ITypeInfo [que permite el comportamiento de reflexión]. En PowerShell, un objeto COM que implementa IDispatch pero no ITypeInfo da como resultado un conjunto extraño de restricciones, que es lo que está notando.

El proveedor ADSI de WinNT tiene al menos 15 años de antigüedad y nunca ha sido una característica sólida. Era un marcador de posición escrito antes de que se enviara Active Directory (mucho antes de CLR o PowerShell). En aquel entonces, ''scripting'' en Microsoft significaba versiones anteriores de VBScript, con algún soporte para JScript, que se basaban en IDispatch y nunca usaban ITypeInfo.

Este fue un tema de discusión al principio de la vida de PowerShell, cuando uno de los miembros del equipo de PowerShell dijo:

14 de julio de 2006

... PowerShell no puede mostrar los métodos de los objetos COM si no se proporciona la interfaz ITypeInfo. Esto será arreglado pronto. La solución alternativa es utilizar Type.InvokeMethod ().

Ha habido mejoras en el soporte de PowerShell de los objetos COM, pero una solución completa nunca se materializó. Creo que el miembro del equipo puede haber prometido en exceso lo que es técnicamente posible. Esto puede haber confundido a la gente. Le pregunté a un desarrollador líder amigo mío sobre el equipo sobre esto hace un par de años; él estaba claramente familiarizado con el problema e indicó que el caso de uso no era de alta prioridad y mencionó la solución también.

El equipo de PowerShell ha estado enviando funciones impresionantes y algunas correcciones de errores, pero, francamente, no creo que este problema llegue a ser la barra de errores.