@mklement0 @adamdriscoll @rkeithhill @CollinChaffin @msftrncs @markekraus @vexx32 @SteveL-MSFT @daxian-dbw @iRon7 @mdalepiane
Welcome to download compiled artifact and discuss. Please also look failed tests that can be useful for the discussion.

@iSazonov Can we please move this forward as a new, standalone library that is compatible with Windows PowerShell 5.1 as well as PowerShell 7.x? The issues identified here are also issues in 5.x. There have been enhancements in the cross platform PowerShell such as -EnumsAsStrings and -AsHashtable and -AsArray and -EscapeHandling that are not available to Windows PowerShell 5.1. Yet there are scenarios where simply pointing users to PowerShell 7 as the solution forward is not viable. Plus there are discussions here about breaking changes. A standalone module that carries JSON conversion forward using the .NET Core JSON APIs while addressing the bulk of the issues with JSON in PowerShell today (including fully bi-directional conversion) would be a much better way to bring the Microsoft JSON.NET libraries into PowerShell than simply updating what we have as a built-in module that isn't available elsewhere.

Also this hasn't moved forward in some time. Is that partly due to concerns about these breaking changes? If so, again, a standalone optional module that supersedes what Windows PowerShell 5.1 and PowerShell 7.x have baked in today seems like a better solution.

Looking at the code, I see you've implemented an entirely new set of classes, so hopefully it should be straightforward to move that into a standalone module that could work for Windows PowerShell 5.1 as well as PowerShell 7.x.

Also, while it seems like this is covered, a use case that I want to specifically call out is the need to access the conversion to/from JSON via an API, so that the same logic that is used within PowerShell can be used in products that leverage PowerShell without having to invoke PowerShell directly. Please make sure this use case is covered.

If the conversion logic was localized within a library that PowerShell 7.x used in cmdlets, and if that library was packaged up as a Nuget package, that would cover the needs of developers building solutions on top of PowerShell as well -- at least in my case it would.

One more thing @iSazonov: I have immediate need for this in Windows PowerShell 5.1, or as a library, and I'm happy to assist with the development and testing. I don't want to simply create duplicate work in parallel though, so please let me know what the plans are to move this forward, whether or not you think creating this as a standalone module is feasible and something you agree with, and we'll go from there. If you're too busy and you'd like me to move this forward, I'm happy to do so.

@SteveL-MSFT: Curious to hear your thoughts on the idea of this being broken out into a separate module and NuGet library (library necessary to consume/convert from JSON produced from PowerShell scripts in an environment that does not run PowerShell).

Does this PR resolve #3705 such that the -AsHashtable workaround is not required? i.e. With a case insensitive JSON conversion logic, what happens when it is fed some json that contains case-sensitive property names? Hopefully it has an option to just write each value once, because in scenarios where you can get duplicate property names with the same values but a different case, it would be nice if you could just ignore those scenarios.

An example where such a scenario can occur is this:
Get-ADUser -Filter * -Properties * | ConvertTo-Json | ConvertFrom-Json

That will generate JSON containing both ObjectGuid and ObjectGUID, both of which contain the same value.

I am fan .Net Runtime development model. I strongly sure we could benefit from the dev model too. They put all code dev process in one repository and greatly simplify it. As result they get huge community contributions.
With the model all you would need to do you would add publishing of a new nuget package.

Unfortunately, PowerShell MSFT team cannot find a middle ground - many community PRs are frozen here and PowerShell/modules repository does not work at all.
Of course, you can always develop your own project to meet your needs... I suspect that if you need quick results today, then you are destined for it (own project). :-(

Also this hasn't moved forward in some time. Is that partly due to concerns about these breaking changes?

My intentions were:

• to create early implementation so that we can feedback to .Net team while they actively worked on .Net 5.0.
• to avoid breaking changes as possible and pass all our current tests without changes
• later to add new fixes in separate commits so that we explicitly see new breaking changes.

As for breaking changes, there are two places:

• in .Net
  They implemented new API with compatibility with NewtonSoft Json.Net and fix some bugs and inconsistences. As result the new API has many breaking changes compared with Json.Net ( and PowerShell too because PowerShell uses Json.Net)
• in PowertShell
  PowerShell has bugs and inconsistences too. Fixing its will add breaking changes.

In the end, we come to the conclusion that in any case, when we switch to the new API, we will receive many breaking changes. I hoped that we get this in 7.1 as experimental feature for easy community adoption. But :-(

a use case that I want to specifically call out is the need to access the conversion to/from JSON via an API, so that the same logic that is used within PowerShell can be used in products that leverage PowerShell without having to invoke PowerShell directly.

Only specific convertor is created for PSObject. Do you ask to put it in nuget library and reference SMA (PowerShell SDK)?

I have immediate need for this in Windows PowerShell 5.1, or as a library, and I'm happy to assist with the development and testing.

Press MSFT team :-) to follow .Net Runtime dev model. This is my strict belief. A good development environment is 80 percent of the effort. If we do this in one place, we will significantly speed up development.

Does this PR resolve #3705 such that the -AsHashtable workaround is not required?

This was not my goal. As I said, I wanted to avoid any breaking changes and bug fixes and make them explicitly later.

@iSazonov Thank you for the detailed reply.

Of course, you can always develop your own project to meet your needs... I suspect that if you need quick results today, then you are destined for it (own project). :-(

This is what we have now -- some proxy functions to override the ConvertTo-Json/ConvertFrom-Json cmdlets where needed. But ultimately I don't want to spend time on something that should come from PowerShell itself as a separate module, and I don't want to own the development of something that is so fundamental that it really should be managed by Microsoft. I'm doing it because I have to, but with bugs like #3705 plus performance benefits from switching to .NET Core JSON APIs, I'd rather converge on a PowerShell team-managed solution than roll my own, because I have much bigger things to focus on that are far more important than JSON conversion (which should be something people can simply take for granted as being there with a solid, performant implementation, in both Windows PowerShell and PowerShell).

In the end, we come to the conclusion that in any case, when we switch to the new API, we will receive many breaking changes. I hoped that we get this in 7.1 as experimental feature for easy community adoption. But :-(

I think a standalone module and Nuget package would be far superior to an experimental feature in this case. But I suppose I already said that.

Only specific convertor is created for PSObject. Do you ask to put it in nuget library and reference SMA (PowerShell SDK)?

That would be fine. I have no problem needing the PowerShell SDK as a dependency. I'm already using it. I'm also only looking for conversion to/from PS entities such as PSObject, Hashtable, etc. I just want to avoid needing to call into PowerShell when I already have my object data that needs conversion in my C# code.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

Any idea what is needed to get this PR ready to go? I see a couple of things but if you've got a list that would be super helpful

Any idea what is needed to get this PR ready to go? I see a couple of things but if you've got a list that would be super helpful

I can not do all work - investigate, develop, review and merge :-) If you have an interest you could grab the PR. I guess we could get this working in one-two weeks and then switch to ConvertFrom-Json.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author