Working with Objects

Analogy categoryAnalogies

PowerShell Objects Are .NET Objects

Every value that a PowerShell cmdlet returns is an instance of a real .NET type, complete with a type name, a set of properties, and often methods you can call. What you see printed to the console is only a default text rendering of that object; the object itself carries far more data than what's displayed, and that hidden data is exactly what later pipeline stages can query.

🏏

Cricket analogy: A player's scorecard entry isn't just a number — it's an object with runs, balls faced, strike rate and dismissal type bundled together, exactly like a PowerShell object carrying properties beyond its printed text.

Discovering Properties and Methods with Get-Member

The Get-Member cmdlet, often abbreviated gm, reveals the full shape of any object piped into it: its TypeName, every Property with its data type, and every Method you can call, including ones never shown in the default console output. This makes Get-Member the single most useful discovery tool when working with an unfamiliar cmdlet's output.

🏏

Cricket analogy: Get-Member is like pulling up a player's full profile on a cricket stats app — batting average, bowling figures, fielding stats — instead of just seeing their name on the scoreboard.

powershell

Get-Process | Get-Member -MemberType Property

# Inspect a single object's real type
Get-Process | Select-Object -First 1 | Get-Member | Select-Object -First 1 TypeName

Accessing Properties and Calling Methods

Dot notation reads a property or invokes a method on an object: $process.ProcessName returns a stored value directly, while $process.Kill() performs an action that changes the state of the system. The parentheses matter — omitting them on a method just returns a description of the method rather than executing it — and inside pipeline script blocks the same dot notation is used on $_, as in $_.Status.

🏏

Cricket analogy: Writing $player.Average is like flipping straight to a specific stat on a player's profile page, while $player.CalculateStrikeRate() is like asking the system to compute a new figure on demand.

Every object's default console output is produced by calling its .ToString() method or a matching .ps1xml view, which can hide most of the object's actual data. Never assume an object only has what you see printed — always check with Get-Member first.

Creating Custom Objects

The [PSCustomObject] type accelerator, combined with a hashtable literal, is the standard way to build your own structured objects from scratch, letting you define exactly which named properties should exist in a fixed order. This is the preferred technique for producing clean report rows or combining data pulled from several different sources into one consistent shape.

🏏

Cricket analogy: Building a [PSCustomObject] is like a scorer manually creating a new stat line for an unlisted player — you define exactly which fields (Runs, Overs, Wickets) belong on that card.

Building objects with New-Object PSObject and then Add-Member for each field is far slower and more verbose than [PSCustomObject]@{ Name = 'Value' }. Reserve the older Add-Member approach for cases where you need to attach a property to an existing object after the fact.

Every PowerShell output value is a typed .NET object, not just displayed text.
Get-Member (gm) lists an object's real TypeName, properties, and methods.
Dot notation reads a property directly; calling a method with () performs an action.
The console's default view is only a rendering — objects usually carry more data than is shown.
[PSCustomObject]@{ ... } is the standard, fast way to build your own structured objects.
Prefer [PSCustomObject] over New-Object plus Add-Member for new objects.