Using Select-Object -ExpandProperty Updates Source PSCustomObjects #21308

BinaryWizard904 · 2024-03-05T19:11:03Z

Prerequisites

Write a descriptive title.
Make sure you are able to repro it on the latest released version
Search the existing issues.
Refer to the FAQ.
Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

In PowerShell v7.4.1, when you use Select-Object to select a custom column from a nested PSCustomObject object and then use -ExpandProperty to retrieve the contents of a child object, the custom column will be appended to the selected child object in the source object. This is unexpected as Select-Object documentation states that using both -Property and -ExpandProperty should only, "[attempt] to add each selected property as a NoteProperty to every outputted object".

There is nothing in the documentation about Select-Object altering the source object as well. Moreover, while technically a breaking change, fixing this was green-lit in #7768 (comment) by the @PowerShell/powershell-committee, but improperly implemented using PSObject.AsPSObject().

Example:

function Test-Select {
	$obj = [PSCustomObject]@{
		"name"="admin1"
		"children"=[PSCustomObject]@{
			"name"="admin2"
		}
	}

	Write-Host "`$obj.children Before Selection" -ForegroundColor Cyan
	Write-Host $obj.children

	Write-Host "`nSelected Object" -ForegroundColor Cyan
	Write-Host ($obj | Select-Object @{N="country";E={$_.name}} -ExpandProperty children)

	Write-Host "`n`$obj.children After Selection" -ForegroundColor Cyan
	Write-Host $obj.children
}

Expected behavior

PS> Test-Select
$obj.children Before Selection
@{name=admin2}

Selected Object
@{name=admin2; country=admin1}

$obj.children After Selection 
@{name=admin2}

Actual behavior

PS> Test-Select
$obj.children Before Selection
@{name=admin2}

Selected Object
@{name=admin2; country=admin1}

$obj.children After Selection 
@{name=admin2; country=admin1}

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.4.1
PSEdition                      Core
GitCommitId                    7.4.1
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

The text was updated successfully, but these errors were encountered:

mklement0 · 2024-03-05T20:17:55Z

This was first discussed in 2018 in #7768 and change was actually green-lit and marked as up-for-grabs, but no one has stepped up to implement, and the microsoft-github-policy-service bot closed it due to inactivity (something that I think should never happen for green-lit changes).

Though, what change, precisely, was green-lit is a bit murky.

The preceding discussion is very long, but perhaps starting here helps.

BinaryWizard904 · 2024-03-05T21:30:43Z

@mklement0, thanks for bringing that one to my attention. Didn't find it on my first pass. As for what was greenlit, I wouldn't consider it murky. They said "We believe the original intent is to not modify the original object [and] we should just fix the original behavior so that a new object is emitted." i.e., Select-Object should never modify the source object but should instead emit a new one.

I'll take a look and see if I can come up with anything that fixes this.

BinaryWizard904 · 2024-03-05T22:07:21Z

Weird thing is that I'm seeing code comments indicating that this was already addressed. Did some more looking, and I think the issue might lie here:

PowerShell/src/Microsoft.PowerShell.Commands.Utility/commands/utility/Select-Object.cs

Lines 548 to 553 in ad2bf78

    
           // add NoteProperties if there is any 
        
           // If r.Result is a base object, we don't want to associate the NoteProperty 
        
           // directly with it. We want the NoteProperty to be associated only with this 
        
           // particular PSObject, so that when the user uses the base object else where, 
        
           // its members remain the same as before the Select-Object command run. 
        
           PSObject expandedObject = PSObject.AsPSObject(r.Result, true);

PSObject.AsPSObject() has interesting code in that if the input object is itself a PSObject, it will return a reference to the original object instead of a new one. Only if the object is not a PSObject will it create a new one.

PowerShell/src/System.Management.Automation/engine/MshObject.cs

Lines 1049 to 1054 in ad2bf78

    
           if (obj is PSObject so) 
        
           { 
        
               return so; 
        
           } 
        
           return new PSObject(obj) { StoreTypeNameAndInstanceMembersLocally = storeTypeNameAndInstanceMembersLocally };

Given the comments in Select-Object, I don't think this was expected by the programmer and it is likely why this issue only affects PSObjects and their derivatives. Other objects like Hash Tables are not affected.

Always copy the source object instead of referencing it. PowerShell#21308

mklement0 · 2024-03-05T22:58:58Z

Nice sleuthing.

The immediate fix to the problem at hand is probably something like (a custom object has no base object):

PSObject expandedObject = 
  r.Result is PSObject && r.Result.BaseObject is PSCustomObject ?
    r.Result.Copy() : PSObject.AsPSObject(r.Result, true);

However, this - intended - per-PSObject-instance-wrapper way of attaching ETS properties that applies to all other types is problematic in itself, as also discussed in the linked issue, and it is responsible for the bugs reported in #7937 and #12411

~~Therefore, to me the proper fix - which is also technically breaking - is to use the resurrection-table approach to attaching the ETS properties for non-PSCustomObject type instances:~~ (see comment below)

// Note the `false` argument.
PSObject expandedObject = 
  r.Result is PSObject && r.Result.BaseObject is PSCustomObject ?
    r.Result.Copy() : PSObject.AsPSObject(r.Result, false);

BinaryWizard904 · 2024-03-06T00:32:08Z

@mklement0 I don't think that solution would work as this issue affects PSObject in general, not just the PSCustomObject.
Example:

$obj = [PSObject]@{"name"="admin1";"children"=[PSObject]@{"name"="admin2"}}
$obj | Select-Object @{N="country";E={$_.name}} -ExpandProperty children
$obj.children.country

# Results in "admin1" when it should be $null.

Moreover, the Copy method actually preserves ETS properties through the use of ResurrectionTables, so we won't be loosing things.

PowerShell/src/System.Management.Automation/engine/MshObject.cs

Line 1588 in ad2bf78

    
           // Instance members will be recovered as necessary through the resurrection table.

PowerShell/src/System.Management.Automation/engine/MshObject.cs

Lines 1610 to 1630 in ad2bf78

    
           // needToReAddInstanceMembersAndTypeNames = returnValue will have a different key (different from "this") returned from GetKeyForResurrectionTables 
        
           bool needToReAddInstanceMembersAndTypeNames = !object.ReferenceEquals(GetKeyForResurrectionTables(this), GetKeyForResurrectionTables(returnValue)); 
        
           if (needToReAddInstanceMembersAndTypeNames) 
        
           { 
        
               Diagnostics.Assert(!returnValue.InstanceMembers.Any(), "needToReAddInstanceMembersAndTypeNames should mean that the new object has a fresh/empty list of instance members"); 
        
               foreach (PSMemberInfo member in this.InstanceMembers) 
        
               { 
        
                   if (member.IsHidden) 
        
                   { 
        
                       continue; 
        
                   } 
        
                   // Add will clone the member 
        
                   returnValue.Members.Add(member); 
        
               } 
        
               returnValue.TypeNames.Clear(); 
        
               foreach (string typeName in this.InternalTypeNames) 
        
               { 
        
                   returnValue.TypeNames.Add(typeName); 
        
               } 
        
           }

Testing confirms this.

$v = [datetime]::now; $v | Add-Member myProp myPropValue
$v2 = $v.PSObject.Copy()
$v2.myProp
# results in "myPropValue"
$v3 = [PSCustomObject]@{prop = $v}
$v4 = $v3.PSObject.Copy()
$v4.prop.myProp
# results in "myPropValue"

mklement0 · 2024-03-06T03:02:38Z

My interest in delving into the depths of this is limited, but let me offer the following observations:

Perhaps surprisingly, [psobject] and [pscustomobject] are both System.Management.Automation.PSObject- see Why is [pscustomobject] the same as [psobject], even though a distinct [System.Management.Automation.PSCustomObject] type exists? #4344. However, they're not the same when used as (ostensible) casts.
[PSObject]@{"name"="admin1";"children"=[PSObject]@{"name"="admin2"}} doesn't create a [pscustomobject], as only the latter works as syntactic sugar with @{ ... } - instead, it simply wraps the hashtable resulting from the hashtable literal in a (mostly, but not always - see Objects are situationally invisibly [psobject]-wrapped, sometimes causing unexpected behavior. #5579) invisible [psobject] wrapper - verify with ([PSObject]@{"name"="admin1";"children"=[PSObject]@{"name"="admin2"}}).GetType().FullName (yields 'System.Collections.Hashtable')
Indeed, my suggestion was that for System.Management.Automation.PSObject instances that aren't just containers for System.Management.Automation.PSCustomObject (the "property bags" for PSObject instances that have no .BaseObject) and instead wrap instances of regular .NET types, the ETS decoration should be based on the resurrection tables for the latter.
- In other words:
  - Create copies of instances that are ultimately System.Management.Automation.PSCustomObject instances (property bags) in which case the decoration only affects those instances - this is the special-casing that Select-Object modifies input objects when using both -ExpandProperty and -Property #7768 ultimately called for.
  - For all other types - and this is debatable and not covered by the committee decision - decorate the instances via the resurrection tables, so as to avoid the surprises in Select-Object -ExpandProperty hides ETS instance members #7937 and Select-Object -ExpandProperty combined with -Property fails to add ETS instance members to non-primitive value types #12411 - though I now see that the latter problem has seemingly gone away, for reasons unknown to me.

PowerShell#21308

BinaryWizard904 · 2024-03-06T21:27:46Z

@mklement0, thanks for going a bit deeper into this with me. I appreciate all these details, they helped me figure out how I could implement it.

It was a huge pain getting this working as I haven't been able to build PowerShell locally, even in Dev Containers. But it finally builds in CI, and it passes the new Pester tests for #21308 and #7937. PR: #21310

Describe "Select-Object with ExpandProperty" -Tags "CI" {

    # Issue #7937
    It "Select-Object with ExpandProperty preserves ETS instance members" {
        $obj = [DateTime]::Now
        $obj | Add-Member myProp myPropValue
        $results =  [PSCustomObject] @{ prop = $obj } | Select-Object -ExpandProperty prop
        $results.myProp | Should -BeExactly "myPropValue"
    }

    # Issue #21308
    It "Select-Object with ExpandProperty and Calculated Property does not modify source object" {
        $obj = [PSCustomObject]@{"name"="admin1";"children"=[PSCustomObject]@{"name"="admin2"}}
        $obj | Select-Object -Property @{N="country";E={$_.name}} -ExpandProperty children | Out-Null
        $obj.children.country | Should -BeNullOrEmpty
    }
}

mklement0 · 2024-03-06T23:03:49Z

Glad to hear it, @BinaryWizard904, and thanks for tackling a fix (I see that it isn't a PR yet).

It looks like what you've done covers the committee decision, and I now realize, after re-reading the original source-code comments, that the intent indeed appears to be not to use the resurrection tables for the ETS members to be attached for any -Property arguments and to instead attach them to the incidental [psobject] instance being created, which has the following implications:

On the plus side, it doesn't affect Select-Object's input objects, as desired.
- The downside of that is that it's easy to "lose" this incidental wrapper, via casts and during parameter binding, causing the loss of the ETS properties as well.
However, any preexisting resurrection table-based ETS properties are eclipsed in the process, as demonstrated below.
Also, if the -ExpandProperty target property happens to be a an incidentally [psobject]-wrapped non-custom object (incidental wrappers are created for objects output by cmdlets, for instance) that also happens to have resurrection table-based ETS properties, the -Property ETS members will be added to the resurrection tables, and therefore will affect Select-Object's input objects.

(All of these behaviors predate your attempted fix.)

$obj = [DateTime]::Now

# Add ETS property via resurrection tables.
$obj | Add-Member ResurrectionProp 1

# Via Select-Object -ExpandProperty combined with -Property,
# try to add - hopefully *another* - ETS property.
# However, because this creates an incidental [psobject] wrapper that
# has ONLY the -Property-specified properties attached, the original,
# resurrection-table property is now *eclipsed*.
$results = [pscustomobject] @{ PSObjectInstanceProp = 2; prop = $obj } | 
  Select-Object -ExpandProperty prop -Property PSObjectInstanceProp

[pscustomobject] @{
  ResurrectionProp = $results.ResurrectionProp
  PSObjectInstanceProp = $results.PSObjectInstanceProp
}

Output, showing that the resurrection table-based property is now eclipsed:

ResurrectionProp PSObjectInstanceProp
---------------- --------------------
                                    2

BinaryWizard904 · 2024-03-06T23:53:21Z

@mklement0, knew I forgot something. The PR is: #21310

That said, if you now don't think fixing #7937 is in the cards, I'll need to rewrite things a bit.

mklement0 · 2024-03-07T03:03:01Z

@BinaryWizard904: Fundamentally, I think it's important to explicitly spell out all the ramifications of the change in the PR description.

As for what I think the behavior should be, following the discussions so far:

If no -Property argument is present, the raw values of the property specified via -ExpandProperty should be emitted (which, via, .WriteObject, end up incidentally [psobject] wrapped), which preserves any preexisting resurrection-table entries for non-custom objects as well as for PSObject-wrapped objects that have per-instance ETS members.
Otherwise, assuming the overall design goal of not modifying the emitted object - neither via directly adding members to custom objects nor via adding members to non-custom objects via the resurrection tables:
- A custom object (such as constructed via [pscustomobject] @{ ... }), i.e. a PSObject instance that has no .BaseObject and only contains directly attached ETS members via a PSCustomObject, should be (shallow-)cloned, via .Copy(), before attaching the properties implied by -Property.
- A PSObject instance with a .BaseObject that already has per-instance ETS members should be cloned via .Copy() too - the challenge is that you cannot currently determine the presence of per-instance ETS members from the outside, because the StoreTypeNameAndInstanceMembersLocally property is private.
- Any other object (whether incidentally PSObject-wrapped or not) that has existing resurrection-table ETS members: create a (new) PSObject wrapper with per-instance ETS behavior (.AsPSObject(objectOrBaseObject, true)) and add copies of the resurrection-table members to it.
- Any other object('s .BaseObject) should be wrapped with .AsPSObject(objectOrBaseObject, true), to create a [psobject] wrapper with per-instance ETS members.

On a meta note:

In hindsight, it feels like allowing -ExpandProperty to be combined with -Property created more problems than it solved; unfortunately, it's too late to take that feature away.

BinaryWizard904 · 2024-03-07T16:24:54Z

@mklement0 I do not believe we need to differentiate PSCustomObject from PSObject as the particular code being changed here has always (and continues) to treat both the same. In my mind, at least as far as this particular problem goes, it doesn't matter whether the source is a a PSCustomObject or just a plain PSObject; Select-Object currently alters source objects of both types when it should not, and the solution (using .Copy()) is the same for both.

While it is true the the logic in the .Copy() method is more complex and does have a minor bit of logic to treat them differently, I'm not actually touching that.

Anyways, with your words in mind I have updated the PR description. After further thought I believe we can still resolve both this and #7937 as resolving the latter isn't breaking so much as additive. And if not, well I think I've made clear all that needs changing to remove the fix for #7937 without preventing a fix for this issue is to flip a boolean argument and remove or invert the Pester test.

I don't think it was ever really feasible not to allow users to combine -ExpandProperty and -Property. The moment we allowed nested datasets was the moment people would need a way to flatten them. I for example often need to load REST API returns into an RDBMS database.

mklement0 · 2024-03-07T19:41:20Z

In part due to my hesitancy to dig into the source code, my previous comment was meant to spell out all cases that need to be considered conceptually.

It's great if the existing code allows translating that into fewer cases in the implementation.

However, your PR currently doesn't cover all these cases, from what I can tell.

The following, extended version of your first Pester test tries to cover all cases I've described:

Update: see below

Describe 'Select-Object with ExpandProperty' -Tags 'CI' {

  # Issue #7937
  It 'Select-Object with ExpandProperty preserves ETS instance members' {
    # Use a .NET reference type, because the copy semantics of value types
    # could hide some behaviors.
    $obj = [regex] 'foo'
    # Add a property via the resurrection tables.
    $obj | Add-Member resurrectTableProp 1
    # Now embed the object inside another object and extract it via -ExpandProperty,
    # while also decorating it via another property using -Property.
    $results =
      [PSCustomObject] @{ psobjectWrapperProp = 2; prop = $obj } |
      Select-Object -ExpandProperty prop -Property psobjectWrapperProp
    # Make sure the resurrection-table member is still present.
    $results.resurrectTableProp | Should -BeExactly 1
    # Make sure the directly [psobject]-attached member is also present.
    $results.psobjectWrapperProp | Should -BeExactly 2
    # Make sure that the original object doesn't unexpectedly see the
    # directly [psobject]-attached member.
    $obj.psobjectWrapperProp | Should -BeExactly $null
    # --
    # Inverse test:
    # Make sure that the resurrection-table member is still that
    # (didn't unexpectedly become a directly [psobject]-attached member.)
    $results.psobject.BaseObject.resurrectTableProp | Should -BeExactly 1
    # Make sure the directly [psobject]-attached member didn't unexpectedly
    # become a resurrection-table member.
    $results.psobject.BaseObject.psobjectWrapperProp | Should -BeExactly $null
  }

  # Issue #21308
  It 'Select-Object with ExpandProperty and Calculated Property does not modify source object' {
    $obj = [PSCustomObject]@{'name' = 'admin1'; 'children' = [PSCustomObject]@{'name' = 'admin2' } }
    $obj | Select-Object -Property @{N = 'country'; E = { $_.name } } -ExpandProperty children | Out-Null
    $obj.children.country | Should -BeNullOrEmpty
  }
}

That is, unless I'm missing something, it looks like the psobjectWrapperProp property, which should be attached to the output [psobject] wrapper only, unexpectedly ended up in the resurrection table for the original object ($obj).

Failure:

[-] Select-Object with ExpandProperty.Select-Object with ExpandProperty preserves ETS instance members 432ms (420ms|12ms)
 Expected exactly $null, but got 2.
 at $obj.psobjectWrapperProp | Should -BeExactly $null, /Users/jdoe/pg.Tests.ps1:117

Similarly, the effectively equivalent later $results.psobject.BaseObject.psobjectWrapperProp | Should -BeExactly $null test would fail (preempted by the first failure).

As for the merits of combining -ExpandProperty and -Property: you're right, it is a convenient way of reshaping objects, but arguably only of custom objects, i.e. dynamically expandable "property bags" - as opposed to tacking on non-native ETS members to regular .NET types, which may or may not automatically surface later.

mklement0 · 2024-03-07T20:02:35Z

P.S.:

The above test was written under the assumption that a composite view of ETS members is possible, in other words that a given [psobject]-wrapped (non-custom) object surfaces both wrapper-attached and resurrection table-based ETS members, if both exist.

However, I suspect that's not actually supported - hence the suggestion in my conceptual description to copy resurrection table-based members to the wrapper before attaching the -Property-specified ones.

mklement0 · 2024-03-07T21:46:32Z

Indeed, such a composite view (a single, [psobject]-wrapped object surfacing both directly attached ETS members as well as resurrection table-based ones) isn't supported, which implies:

For resurrection table-based ETS members not to be lost when [psobject] wrapper-attached properties are added via -Property, they must be copied to the wrapper first.
If this is considered too much of an edge case to bother with, it would need to be clearly documented.
Either way, the currently failing (with your PR) $obj.psobjectWrapperProp | Should -BeExactly $null tests should pass, as it contradicts the goal of not modifying the object targeted by -ExpandProperty

Here are the updated Pester tests:

Describe 'Select-Object with ExpandProperty' -Tags 'CI' {

  # Issue #7937
  It 'Select-Object with ExpandProperty preserves ETS instance members' {
    # Use a .NET reference type, because the copy semantics of value types
    # could hide some behaviors.
    $obj = [regex] 'foo'
    # Add a property via the resurrection tables.
    $obj | Add-Member resurrectTableProp 1
    # Now embed the object inside another object and extract it via -ExpandProperty,
    # while also decorating it via another property using -Property.
    $results =
      [PSCustomObject] @{ psobjectWrapperProp = 2; prop = $obj } |
      Select-Object -ExpandProperty prop -Property psobjectWrapperProp
    # Make sure the resurrection-table member is still present, due to having
    # been copied to the [psobject] wrapper.
    $results.resurrectTableProp | Should -BeExactly 1
    # Make sure the directly [psobject] wrapper-attached member, via -Property,
    # is also present.
    $results.psobjectWrapperProp | Should -BeExactly 2
    # Make sure that the original object doesn't unexpectedly see the
    # -Property-specified property, i.e. that it wasn't mistakenly added to the
    # the resurrection tables instead of being directly attached to the [psobject] wrapper.
    $obj.psobjectWrapperProp | Should -BeExactly $null
  }

  # Issue #21308
  It 'Select-Object with ExpandProperty and Calculated Property does not modify source object' {
    $obj = [PSCustomObject]@{'name' = 'admin1'; 'children' = [PSCustomObject]@{'name' = 'admin2' } }
    $obj | Select-Object -Property @{N = 'country'; E = { $_.name } } -ExpandProperty children | Out-Null
    $obj.children.country | Should -BeNullOrEmpty
  }
}

BinaryWizard904 · 2024-03-07T22:31:13Z

I've reverted the PR to a draft WIP while I get this figured out. You're right about the new tests failing. I will see what I can do to fix it.

BinaryWizard904 · 2024-03-08T23:58:54Z

So I've figured out how to get it to pass every test except $results.resurrectTableProp | Should -BeExactly 1. Oddly, $results.psobject.BaseObject.resurrectTableProp | Should -BeExactly 1 passes just fine, so the resurrectTableProp value it technically still accessible (the same as it is now); the property just isn't being copied as one would expect.

That said, I have tried a number of things but have been unable to so much as detect ETS members, much less copy them. Unless you have an idea on implementation, I don't think I'll be able to fix it. We will just have to be happy with unchanged behavior.

I think I'm also going to need to open a new branch and pull as the existing ones have gotten...crowded. I still haven't been able to get PowerShell to build myself due to git describe errors, so all the tests have been done by CI testing. That said, to help other people figure out what I've tried here are links to the relevant things:

Alter GetKeyForResurrectionTables method in MshObject.cs to copy when StoreTypeNameAndInstanceMembersLocally is true.
Create a separate AddResurrectionProperties method to find and copy ETS members.

jborean93 · 2024-03-10T02:00:54Z

I still haven't been able to get PowerShell to build myself due to git describe errors, so all the tests have been done by CI testing.

Make sure you fetch all the remote tags, it is needed in the build process and failing to do so causes git describe to return non-0 rc's failing the build.

BinaryWizard904 · 2024-03-11T14:27:54Z

@jborean93 In a dev container, I ran git fetch --tags --recurse-submodules=true from the top of the repo but that did nothing. I also tried running it from the base of each of the problem projects, but that also did nothing.

PS /workspaces/PowerShell> git fetch --tags --recurse-submodules=yes 
PS /workspaces/PowerShell> Import-Module ./build.psm1
PS /workspaces/PowerShell> Start-PSBuild
WARNING: Could not find 'dotnet', appending /root/.dotnet to PATH.
VERBOSE: In Find-DotNet
VERBOSE: Executing:  dotnet --list-sdks 
VERBOSE: Find-DotNet: dotnetCLIInstalledVersion = 9.0.100-preview.1.24101.2; chosenDotNetVersion = 9.0.100-preview.1.24101.2
VERBOSE: Using configuration 'Debug'
VERBOSE: Using framework 'net9.0'
VERBOSE: Using runtime 'linux-x64'
VERBOSE: Top project directory is /workspaces/PowerShell/src/powershell-unix
VERBOSE: Building without shim
Run dotnet publish /property:GenerateFullPaths=true /property:ErrorOnDuplicatePublishOutputFiles=false --self-contained /property:IsWindows=false --configuration Debug --framework net9.0 --runtime linux-x64 /property:SDKToUse=Microsoft.NET.Sdk from /workspaces/PowerShell/src/powershell-unix
MSBuild version 17.10.0-preview-24101-01+07fd5d51f for .NET
/workspaces/PowerShell/PowerShell.Common.props(18,5): error MSB3073: The command "git describe --abbrev=60 --long" exited with code 128. [/workspaces/PowerShell/src/Microsoft.PowerShell.Security/Microsoft.PowerShell.Security.csproj]
/workspaces/PowerShell/PowerShell.Common.props(18,5): error MSB3073: The command "git describe --abbrev=60 --long" exited with code 128. [/workspaces/PowerShell/src/Microsoft.PowerShell.SDK/Microsoft.PowerShell.SDK.csproj]
/workspaces/PowerShell/PowerShell.Common.props(18,5): error MSB3073: The command "git describe --abbrev=60 --long" exited with code 128. [/workspaces/PowerShell/src/Microsoft.PowerShell.Commands.Utility/Microsoft.PowerShell.Commands.Utility.csproj]
/workspaces/PowerShell/PowerShell.Common.props(18,5): error MSB3073: The command "git describe --abbrev=60 --long" exited with code 128. [/workspaces/PowerShell/src/Microsoft.PowerShell.ConsoleHost/Microsoft.PowerShell.ConsoleHost.csproj]
/workspaces/PowerShell/PowerShell.Common.props(18,5): error MSB3073: The command "git describe --abbrev=60 --long" exited with code 128. [/workspaces/PowerShell/src/Microsoft.PowerShell.Commands.Management/Microsoft.PowerShell.Commands.Management.csproj]
/workspaces/PowerShell/PowerShell.Common.props(18,5): error MSB3073: The command "git describe --abbrev=60 --long" exited with code 128. [/workspaces/PowerShell/src/System.Management.Automation/System.Management.Automation.csproj]
/workspaces/PowerShell/PowerShell.Common.props(18,5): error MSB3073: The command "git describe --abbrev=60 --long" exited with code 128. [/workspaces/PowerShell/src/powershell-unix/powershell-unix.csproj]

Restore failed with errors in 4.4s
Exception: /workspaces/PowerShell/tools/buildCommon/startNativeExecution.ps1:40:17
Line |
  40 |                  throw $errorMessage
     |                  ~~~~~~~~~~~~~~~~~~~
     | Execution of { dotnet $Arguments } by build.psm1: line 561 failed with exit code 1

Always copy the source object instead of referencing it. This ensures that the source object is never implicitly updated by the Select-Object command. PowerShell#21308

BinaryWizard904 · 2024-03-11T18:26:51Z

Alright, I've created a new PR #21328 based on a squashed version of the previous work. There is now one commit, and it passes all related tests.

jborean93 · 2024-03-11T18:57:47Z

In a dev container, I ran git fetch --tags --recurse-submodules=true from the top of the repo but that did nothing. I also tried running it from the base of each of the problem projects, but that also did nothing.

You need to ensure you are fetching the tags from this repo and not your fork. For example

# podman run --rm -it fedora:39

rpm -Uvh https://packages.microsoft.com/config/rhel/9/packages-microsoft-prod.rpm

dnf install -y git powershell

# Substitute this with your fork
git clone https://github.com/jborean93/PowerShell.git
cd PowerShell

# Make sure you use PowerShell/PowerShell, you will see
# multiple tags retrieved when you run it.
git fetch --tags https://github.com/PowerShell/PowerShell.git

# Now the build should work
pwsh -Command 'Import-Module ./build.psm1; Start-PSBootstrap; Start-PSBuild'

src/powershell-unix/bin/Debug/net9.0/linux-x64/pwsh

BinaryWizard904 added the Needs-Triage The issue is new and needs to be triaged by a work group. label Mar 5, 2024

BinaryWizard904 added a commit to BinaryWizard904/PowerShell that referenced this issue Mar 5, 2024

When both Extended Properties and Properties are specified

70e5051

Always copy the source object instead of referencing it. PowerShell#21308

BinaryWizard904 pushed a commit to BinaryWizard904/PowerShell that referenced this issue Mar 6, 2024

Add tests for issues PowerShell#21308

babae76

BinaryWizard904 mentioned this issue Mar 6, 2024

🚧 Prevent Select-Object with ExpandProperty from updating source PSObjects #21310

Closed

8 tasks

BinaryWizard904 pushed a commit to BinaryWizard904/PowerShell that referenced this issue Mar 6, 2024

Restrict PSObject.Copy to PSObjects

490683d

PowerShell#21308

BinaryWizard904 pushed a commit to BinaryWizard904/PowerShell that referenced this issue Mar 7, 2024

Added additional testing per discussion on PowerShell#21308

8ace41d

BinaryWizard904 mentioned this issue Mar 11, 2024

Prevent Select-Object with ExpandProperty from updating source PSObjects #21328

Open

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Using Select-Object -ExpandProperty Updates Source PSCustomObjects #21308

Using Select-Object -ExpandProperty Updates Source PSCustomObjects #21308

BinaryWizard904 commented Mar 5, 2024 •

edited

mklement0 commented Mar 5, 2024

BinaryWizard904 commented Mar 5, 2024

BinaryWizard904 commented Mar 5, 2024

mklement0 commented Mar 5, 2024 •

edited

BinaryWizard904 commented Mar 6, 2024

mklement0 commented Mar 6, 2024 •

edited

BinaryWizard904 commented Mar 6, 2024 •

edited

mklement0 commented Mar 6, 2024 •

edited

BinaryWizard904 commented Mar 6, 2024 •

edited

mklement0 commented Mar 7, 2024 •

edited

BinaryWizard904 commented Mar 7, 2024

mklement0 commented Mar 7, 2024 •

edited

mklement0 commented Mar 7, 2024

mklement0 commented Mar 7, 2024 •

edited

BinaryWizard904 commented Mar 7, 2024

BinaryWizard904 commented Mar 8, 2024

jborean93 commented Mar 10, 2024

BinaryWizard904 commented Mar 11, 2024

BinaryWizard904 commented Mar 11, 2024

jborean93 commented Mar 11, 2024

Using Select-Object -ExpandProperty Updates Source PSCustomObjects #21308

Using Select-Object -ExpandProperty Updates Source PSCustomObjects #21308

Comments

BinaryWizard904 commented Mar 5, 2024 • edited

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

mklement0 commented Mar 5, 2024

BinaryWizard904 commented Mar 5, 2024

BinaryWizard904 commented Mar 5, 2024

mklement0 commented Mar 5, 2024 • edited

BinaryWizard904 commented Mar 6, 2024

mklement0 commented Mar 6, 2024 • edited

BinaryWizard904 commented Mar 6, 2024 • edited

mklement0 commented Mar 6, 2024 • edited

BinaryWizard904 commented Mar 6, 2024 • edited

mklement0 commented Mar 7, 2024 • edited

BinaryWizard904 commented Mar 7, 2024

mklement0 commented Mar 7, 2024 • edited

mklement0 commented Mar 7, 2024

mklement0 commented Mar 7, 2024 • edited

BinaryWizard904 commented Mar 7, 2024

BinaryWizard904 commented Mar 8, 2024

jborean93 commented Mar 10, 2024

BinaryWizard904 commented Mar 11, 2024

BinaryWizard904 commented Mar 11, 2024

jborean93 commented Mar 11, 2024

BinaryWizard904 commented Mar 5, 2024 •

edited

mklement0 commented Mar 5, 2024 •

edited

mklement0 commented Mar 6, 2024 •

edited

BinaryWizard904 commented Mar 6, 2024 •

edited

mklement0 commented Mar 6, 2024 •

edited

BinaryWizard904 commented Mar 6, 2024 •

edited

mklement0 commented Mar 7, 2024 •

edited

mklement0 commented Mar 7, 2024 •

edited

mklement0 commented Mar 7, 2024 •

edited