@yotsuda It seems you lost last commits - I don't see updates.

@iSazonov Sorry, I missed the same pattern in WriteValue. Fixed in 165ed2e.
See: https://github.com/PowerShell/PowerShell/blob/165ed2ef9/src/Microsoft.PowerShell.Commands.Utility/commands/utility/WebCmdlet/ConvertToJsonCommandV2.cs#L1012-L1016

GitHub

PowerShell/src/Microsoft.PowerShell.Commands.Utility/commands/utility/WebCmdlet/ConvertToJsonCommandV2.cs at 165ed2ef970cb4ffa2feb237fac8e019f62d2002 · PowerShell/PowerShell

PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

Please see failed tests.
For "AddMember on JsonObject" I see:

$jstr
{
  "Major": 2,
  "Minor": 3,
  "Build": 4,
  "Revision": 14,
  "MajorRevision": 0,
  "MinorRevision": 14,
  "Note": "a version object",
  "Rev": 14,
  "IsOld": true
}

What is $jstr in V2?

As for 127 serialization I think we can select expected result based on the experimental feature status.

Please see failed tests. For "AddMember on JsonObject" I see:
...
What is $jstr in V2?
As for 127 serialization I think we can select expected result based on the experimental feature status.

Both issues are fixed in the latest commits.

AddMember on JsonObject (Version + ETS):

V2 now produces the same output as V1 for Version objects with ETS properties:

$versionObject = New-Object System.Version 2, 3, 4, 14
$versionObject | Add-Member -MemberType NoteProperty -Name Note -Value "a version object"
$versionObject | Add-Member -MemberType ScriptProperty -Name Rev -Value { $this.Revision }
$versionObject | Add-Member -MemberType ScriptProperty -Name IsOld -Value { $this.Major -lt 3 }
$versionObject | ConvertTo-Json

Output (both V1 and V2):
{
  "Major": 2,
  "Minor": 3,
  "Build": 4,
  "Revision": 14,
  "MajorRevision": 0,
  "MinorRevision": 14,
  "Note": "a version object",
  "Rev": 14,
  "IsOld": true
}

The fix adds V1-compatible logic: "true primitive types" (string, DateTime, etc.) always serialize as scalars ignoring ETS, while non-primitive STJ scalar types (Version, IPAddress, etc.) serialize as objects when they have ETS properties.

[char]127 serialization:

Implemented as you suggested - the test now selects expected result based on experimental feature status:

$expectedToJson = $testCase.ToJson
if ($testCase.ToJsonV2 -and (Get-ExperimentalFeature PSJsonSerializerV2).Enabled)
{
    $expectedToJson = $testCase.ToJsonV2
}

• V1: "" (DEL control character disappears)
• V2: "\u007F" (correct Unicode escape)

Commit: 8efb723

@yotsuda Please look failed test.

@iSazonov Thank you for pointing this out. I apologize for the delayed response to the CI test failures. I was running ConvertTo-Json.Tests.ps1 locally before commits, but I missed running Json.Tests.ps1, which contains the AddMember on JsonObject test.

CI Test Failures

Root Cause Analysis

The root cause of the AddMember on JsonObject failure is a mismatch between STJ's JsonTypeInfoKind classification and V1's explicit type handling:

STJ returns Kind=None for types with registered JsonConverters (like Version), but V1's ProcessValue (JsonObject.cs:554-567) has an explicit type list that does NOT include Version, so V1 treats it as an object and enumerates its properties.

Background: Option C Implementation

In PR #26637, you suggested Option C to track raw vs PSObject instead of using a hardcoded type list. Based on this, I replaced the hardcoded IsPrimitiveType list with IsStjNativeScalarType() which uses JsonTypeInfoKind to dynamically detect scalar types.

However, STJ's JsonTypeInfoKind.None classification doesn't perfectly align with V1's behavior for all types. System.Version is one such case where STJ reports Kind=None (because it has a registered JsonConverter), but V1 treats it as an object.

Two Possible Fixes

Fix#1: STJ-based with Exception List

if (type == typeof(Version) || type == typeof(Type))
    return false;  // Treat as object, not scalar
return typeInfo.Kind == JsonTypeInfoKind.None;

• Pros: Maintains STJ-based design (Option C spirit), minimal code change
• Cons: Risk of undiscovered mismatches with other types

Fix#2: Revert to V1's Explicit Type List

return obj is string or char or bool or DateTime or DateTimeOffset 
    or Guid or Uri or double or float or decimal or BigInteger;

• Pros: Guarantees V1 compatibility
• Cons: Loses STJ-based classification benefits, reverts the Option C direction we discussed

Local Test Results (Fix#1)

I tested Fix#1 locally:

Proposed Next Steps

1. Apply Fix#1 (or Fix#2 based on your feedback)
2. Remove or fix the tests I added in this PR that fail on Linux/macOS

Which fix do you prefer, or do you have a different solution in mind?

@yotsuda Thanks!

We need to strive for backward compatibility to make it easier to migrate to an updated cmdlet. The same tests should work for both versions.
We already have one exclusion for object type so we could do the same for Version type.
But there is second place for possible fix. There is specific behavior for string and Datetime. Perhaps the fix should be that we create an exclusion list of string, Datetime, Version.

@iSazonov Thank you for the feedback!

I've applied Fix#1 (Version exception) and fixed the cross-platform test issues in commit 6984cf3.

However, I'd like to clarify the difference between string/DateTime and Version handling:

Current Implementation

The code has two separate exclusion mechanisms for different purposes:

V1 Behavior Verification

# string/DateTime: ETS properties are IGNORED
$str = "hello"
$str | Add-Member -NotePropertyName ETS -NotePropertyValue "test" -PassThru | ConvertTo-Json
# Output: "hello"  (no ETS)

# Version: ETS properties are INCLUDED
$ver = [Version]"1.2.3"
$ver | Add-Member -NotePropertyName ETS -NotePropertyValue "test" -PassThru | ConvertTo-Json -Compress
# Output: {"Major":1,"Minor":2,"Build":3,"Revision":-1,...,"ETS":"test"}

Why Not Combine Into One List?

If we added Version to IsV1EtsSkipType (alongside string/DateTime), ETS properties on Version objects would be skipped, breaking backward compatibility.

The current fix correctly handles Version by:

1. Returning false from IsStjNativeScalarType → treats Version as non-scalar
2. NOT adding it to IsV1EtsSkipType → preserves ETS properties

This matches V1 behavior exactly.

Changes in This Commit (6984cf3)

1. Fix#1 applied: Added Version to IsStjNativeScalarType exception list
2. Cross-platform test fixes:
   • Changed pwsh.exe → System.Management.Automation.dll (exists on all platforms)
   • Changed property count check to platform-specific (Windows: 24, Unix: 28)
3. Culture-independent datetime test: Added en-US culture wrapper for locale-dependent assertions in Json.Tests.ps1

Question: V2-Specific Tests

I've created ConvertTo-Json.PSJsonSerializerV2.Tests.ps1 to document V2-specific behaviors that differ from V1 (e.g., non-string dictionary keys support).

If your goal is to make V2 fully compatible with V1, I should:

1. Modify the code to match V1 behavior for these cases
2. Remove the V2-specific tests

Would you like me to pursue full V1 compatibility, or is it acceptable for V2 to have documented behavioral improvements while maintaining compatibility for common use cases?

@yotsuda Thanks for clarify! It was my wrong understanding of Version behavior.

I feel there is another issue. If a type has a custom converter, it return JsonTypeInfoKind.None then we consider it as scalar type and call the type converter without out custom depth control. Yes?

If your goal is to make V2 fully compatible with V1, I should:

I am ok with "non-string dictionary keys support" added.
Version behavior you already fixed.
Are there other breaking changes you mean?

@iSazonov Thank you for the clarification!

Custom Converter + Kind=None

If a type has a custom converter, it return JsonTypeInfoKind.None then we consider it as scalar type and call the type converter without out custom depth control. Yes?

Yes, that's the current behavior. For types with Kind=None:

• If a dedicated converter exists (Double, Float, Type), it handles serialization
• Otherwise, STJ's default serialization is used
• In both cases, no depth control is applied

My understanding is that this is acceptable because these types are "leaf" values:

• Double/Float: PSJsonDoubleConverter outputs a number or string ("Infinity")
• Type: PSJsonTypeConverter outputs AssemblyQualifiedName string

Note: BigInteger has Kind=Object, but PSJsonBigIntegerConverter is registered first, so it's handled before reaching the factory.

If you see any issues with this approach, please let me know.

Other Breaking Changes

Besides the non-string dictionary keys support, I'm not currently aware of other breaking changes, but I may have missed something.

If you have specific scenarios you'd like me to verify, I'd be happy to test them.

If you see any issues with this approach, please let me know.

If an user creates custom class with custom converter the class will not be serialized by our reflection converter with our depth control.

@iSazonov Thank you for the clarification.

You're right - custom converters bypass our depth control. I investigated how V1 handles this.

V1's Approach

V1 never uses [JsonConverter] attributes. Looking at the code:

1. ConvertToJson calls ProcessValue to pre-process the object
2. ProcessValue converts objects to Dictionary<string, object> using reflection (ProcessCustomObject<JsonIgnoreAttribute>)
3. The converted dictionary is then passed to JsonConvert.SerializeObject

Since the original object is converted to a dictionary before being passed to Newtonsoft.Json, any [JsonConverter] attribute on the class is ignored.

Options

1. Keep current (V2 improvement): Allow custom converters to work, accepting that they bypass depth control. Users who define [JsonConverter] attributes likely understand and expect this behavior.

2. Match V1: Ignore [JsonConverter] attributes, force reflection-based serialization with depth control.

   • Technically feasible: Types with [JsonConverter] return Kind=None from JsonTypeInfo
   • Implementation: Add check in CanConvert:

     if (typeToConvert.IsDefined(typeof(JsonConverterAttribute), inherit: true))
     {
         return true;
     }

Which approach do you prefer?

@yotsuda I think it's time to take stock. I feel my expectations that the new code will be simpler, faster and the functionality extensible have not been fulfilled. By creating workarounds, we have lost all the benefits of STJ.
The main problem is depth control.
I think it makes sense to discuss this in .Net Runtime repository.

@iSazonov I really appreciate all your detailed reviews and guidance throughout this PR.

I agree that maintaining V1 compatibility while keeping V2 simple, fast, and extensible has proven to be a difficult balance. Here's a summary of the challenges we encountered:

Intentional improvement in V2: Non-string dictionary keys are now supported (V1 threw an error).

As you noted, these workarounds have added complexity. I hope this code and analysis can serve as useful material for the .NET Runtime discussion. Please let me know if there's anything you'd like me to revise.

@yotsuda Thanks! I opened dotnet/runtime#123424

@yotsuda dotnet/runtime#123424 was closed. There are huge limitations in STJ design and implementation, it's incredible that they'll change anything in the near future. We have to close the PR.
So we will improve the cmdlet code that we have.
You can work on it if you wish. First of all, on backward compatibility tests.

Thanks for your efforts!

@iSazonov Thanks for the clarification and for filing the upstream issue.

I understand STJ migration is not feasible given the design limitations. Closing this PR.

I'll continue with #26639 for compatibility tests. The test failures there are fixed and it's ready for review. Please share your thoughts on additional tests or cmdlet improvements when you have time.

Thanks for your guidance throughout this effort!