Viewing Object Structure (Get-Member)
Because objects play such a central role in Windows PowerShell, there are several native commands designed to work with arbitrary object types. The most important one is the Get-Member command.
The simplest technique for analyzing the objects that a command returns is to pipe the output of that command to the Get-Member cmdlet. The Get-Member cmdlet shows you the formal name of the object type and a complete listing of its members. The number of elements that are returned can sometimes be overwhelming. For example, a process object can have over 100 members.
To see all of the members of a Process object and page the output so you can view all of it, type:
PS> Get-Process | Get-Member | Out-Host -Paging
The output from this command will look something like this:
TypeName: System.Diagnostics.Process
Name MemberType Definition
---- ---------- ----------
Handles AliasProperty Handles = Handlecount
Name AliasProperty Name = ProcessName
NPM AliasProperty NPM = NonpagedSystemMemorySize
PM AliasProperty PM = PagedMemorySize
VM AliasProperty VM = VirtualMemorySize
WS AliasProperty WS = WorkingSet
add_Disposed Method System.Void add_Disposed(Event...
...
We can make this long list of information more usable by filtering for elements we want to see. The Get-Member command lets you list only members that are properties. There are several forms of properties. The cmdlet displays properties of any type if we set the Get-MemberMemberType parameter to the value Properties. The resulting list is still very long, but a bit more manageable:
PS> Get-Process | Get-Member -MemberType Properties
TypeName: System.Diagnostics.Process
Name MemberType Definition
---- ---------- ----------
Handles AliasProperty Handles = Handlecount
Name AliasProperty Name = ProcessName
...
ExitCode Property System.Int32 ExitCode {get;}
...
Handle Property System.IntPtr Handle {get;}
...
CPU ScriptProperty System.Object CPU {get=$this.Total...
...
Path ScriptProperty System.Object Path {get=$this.Main...
...
Note:
The allowed values of MemberType are AliasProperty, CodeProperty, Property, NoteProperty, ScriptProperty, Properties, PropertySet, Method, CodeMethod, ScriptMethod, Methods, ParameterizedProperty, MemberSet, and All.
There are over 60 properties for a process. The reason Windows PowerShell often shows only a handful of properties for any well-known object is that showing all of them would produce an unmanageable amount of information.
Note:
Windows PowerShell determines how to display an object type by using information stored in XML files that have names ending in .format.ps1xml. The formatting data for process objects, which are .NET System.Diagnostics.Process objects, is stored in PowerShellCore.format.ps1xml.
If you need to look at properties other than those that Windows PowerShell displays by default, you will need to format the output data yourself. This can be done by using the format cmdlets.
Posted in: Software| Tags: PowerShell Handle Alias Object Structure Get-Member out-Hosting Paging Process Property ProcessName Allowed MemberType DetermineChanges to the Exception Handling Application Block
The following changes have been made to this version of the Exception Handling Application Block:
- Changed : When building a LoggingExceptionHandler, instead of creating a logging stack every time and ignoring it if the value for the use the default logger flag on the handler is set to true, the build process now uses the value for the flag in the configuration file to create the handler with either Logging.Writer (if true) or the result of creating a new stack (if false). The handler now only knows it has a writer; it does not know where it came from.
- Fixed : The DesignTime nodes for ExceptionHandlers are now handled correctly when using template-based messages. The variables are now accessed correctly when mapping an exception handler configuration object to the corresponding node and a valid configuration is saved.
- Fixed : Invalid XML generated by the XmlExceptionFormatter is fixed. Exception formatters now must include the HandlingInstanceId (which is generated on each exception handling request). The way the exception formatter includes HandlingInstanceId depends on the individual formatter. The XmlExceptionFormatter adds it as an attribute of the top-level Exception element; the TextFormatter adds it as the first line of text. An ID equal to Guid.Empty can be ignored.
The logging exception handler no longer adds the exception handling ID to the message to log. The formatter handles the ID. Exception Formatter types used with the logging exception handler must now implement a constructor with the parameters TextWriter, Exception, and Guid.
There is no backward compatibility support. Creators of custom formatters must update the formatters to be used with this version so that the handling instance ID is not lost because a formatter does not support it.