GeezerVison

The original code is obviously broken.
As for the depth, I am afraid that this fix is not entirely correct. I assume that recursion was originally meant to serialize members.
Michael Klement (@mklement0) What do you think?

Ilya (@iSazonov) I agree that depth limitations are not at all correctly imposed by the serializer right now, but that's a broader issue that should be addressed in a separate issue/PR. This is simply an attempt to not produce invalid XML by fixing an adjecent bug.

For the broader issue of depth limitations we'll need to address the fact that depth is currently ignored by container types as well.

Mathias R. Jessen (@IISResetMe) In the case I'd keep the method signature. And could you please open new issue about the wrong depth ignoring?

I'll revert the last commit, but plan on tackle the depth issue as part of #7290

Ilya (@iSazonov) Reverted depth-related refactorings

Mathias R. Jessen (@IISResetMe) Please add a empty commit with [Feature] in title before we merge..

Please be aware that this issue shouldn't only concern the technical fix of #7290 but also the presumed compatibility with prior versions. Meaning: a lot of scripts in the field might break due to this change!
Refer to the discussion in case #8393 from Michael Klement (@mklement0) and StackOverflow Question "Unexpected ConvertTo-Json results? Answer: it has a default -Depth of 2" concerning the perception of the default -Depth (of 2) of the similar cmdlet: ConvertTo-Json.

iRon7 In the PR we fix a bug in ConvertTo-Xml cmdlet but you reference a ConvertTo-Json - could you clarify that you mean?

I am sorry, I guess my comment wasn't that clear. What I mean is, that appearently every user of the ConvertTo-Json cmdlets appears to trapped by the pitfall that the -Depthis limited by default to 2. The issues with ConvertTo-Xml are less than ConvertTo-Json which could be explained by usage but also by the concerned bug. Meaning that if the default depth now suddenly changes to 2, users might experience the same type of issues as with ConvertTo-Json. Besides, scripts that used to work might now suddenly break and have truncated property paths...

iRon7 The PR doesn't change defaults. It only fix a bug. Defaults we'll change after PowerShell Committee review #7290.

iRon7 one approach could be:

• Fix depth enforcement
• Set default depth = 5

Doesnt have to be 2 just because that's the case for the json cmdlet

Mathias R. Jessen (@IISResetMe). Yes, changing the default depth might work but could cause a performance impact for existing scripts were the default depth (of 2) did work.
E.g.:

Get-Service | ConvertTo-Xml

takes ~700ms, where:

Get-Service | ConvertTo-Xml -Depth 5

takes 6.5 minutes...

Mathias R. Jessen (@IISResetMe)
I still feel the unused method parameters should be removed. Yes, they should eventually be implemented, but since they are not now, they should be removed. It is Ok to add a TODO comment and create an Issue to add the functionality later.

Paul Higinbotham (@PaulHigin) A code you reference is not new code so the change is not related the PR. I believe we get better code with fixing #7290. Mathias R. Jessen (@IISResetMe) Are ready to fix #7290?

takes 6.5 minutes...

iRon7 Please open new performance issue so we can investigate this problem.

Ilya (@iSazonov), I do not have a performance issue (...yet). Just some concerns that the fix (even it is technically correct) might break a few scripts in the field and if you try to prevent that with a higher default -Depth, you might introduce a few performance complains with existing scripts.
Anyway, it is totally up to you what to decide (any direction in this delimema has its pro's and cons).

Steve Lee (@SteveL-MSFT) We need an additional review from MSFT experts and get a conclusion about iRon7's concerns - can we merge before PowerShell Committee review #7290?

I think the scope of these changes is ok to accept without waiting on conclusion of #7290

I just found a similar issue with a PSCustomObject and a recurring reference:

$Parent = [PSCustomObject]@{
	Name = "Parent"
}
$Child = [PSCustomObject]@{
	Name = "Child"
}
$Parent | Add-Member Child $Child
$Child | Add-Member Parent $Parent

But the error message is completely different from #7290

PS C:\> $Parent | ConvertTo-Xml

ConvertTo-Xml : Unexpected end of file has occurred. The following elements are not closed: Objects. Line 9, position 12.
At line:1 char:11

• $Parent | ConvertTo-Xml

•       ~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [ConvertTo-Xml], XmlException
  • FullyQualifiedErrorId : System.Xml.XmlException,Microsoft.PowerShell.Commands.ConvertToXmlCommand

I am not sure whether this is covered in the upcoming fix and tests
Anyways, let me know if you like me to open a new bug report for this.

iRon7 You can download a latest night build from main page of the repo and test.
For your example I get:

$Parent | ConvertTo-Xml

xml                            Objects
---                            -------
version="1.0" encoding="utf-8" Objects