Fix API break: public API must not expose JsonElement objects

[softworkz]

This changes deserialization to the way how it was with
Json.Net: Only .net primitive types are exposed publicly

[Copilot]

Pull Request Overview

This PR addresses an API breaking change by ensuring the public API returns .NET primitive types instead of exposing JsonElement objects directly, restoring compatibility with the previous Json.NET-based behavior.

Key Changes:

• Introduced a new JsonToBoxedPrimitivesConverter that deserializes JSON to boxed primitive types (int, long, double, string, bool, etc.)
• Refactored IpcMain.cs to use the new converter and simplified argument handling to extract the actual payload from IPC messages
• Updated integration tests to verify that received objects are primitive types rather than JsonElement instances

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
src/ElectronNET.API/Serialization/JsonToBoxedPrimitivesConverter.cs	New JSON converter that deserializes to boxed primitive .NET types instead of JsonElement objects
src/ElectronNET.API/API/IpcMain.cs	Refactored to use new converter and simplified FormatArguments to extract payload from IPC message arrays
src/ElectronNET.IntegrationTests/Tests/IpcMainTests.cs	Added assertions to verify received objects are primitive string types, validating the API fix
src/ElectronNET.IntegrationTests/ElectronNET.IntegrationTests.csproj	Disabled nullable reference types to simplify test code

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[softworkz]

@Denny09310 et al.

The serialization changes broke my application. It uses IPC for sending plain strings back and forth to the browser. After the change to System.Text.Json, it started to receive JsonElement objects instead of strings.

The reason for this is that Json.Net fully deserializes everything to .net primitives, but S.T.J still gives you JsonElement objects - e.g. when you deserialize to object[], you get an array for JsonElement - even when it's just strings or other primitives.

I have created a converter which should be close to Json.NET behavior (but there might be tiny differences).

We need to check for other cases...

...where this specific difference might hit in.

Affected are all cases where there's a deserialization to object.

[FlorianRappl]

Great, LGTM!

[FlorianRappl]

Should we keep it open for now or have it in a preview release to invite others to check for differences? In general I see this as a 0.3.0 release. I'll make the changes to develop later today (right now everything is still published as a 0.2.0 preview, even though 0.2.0 is already released).

[softworkz]

A preview release would be great so that I don't need to revert to our private packages :-)
(which version number doesn't matter 0.2.0.xxx-preview is fine )

There are definitely more cases. (I did a search for <object>), but for each one it needs to be determined whether it matters or not. It doesn't matter when the data ist just round-tripped, because it serializes back fine of course. That's also why some tests didn't detect it.
As long as the data remains internal it's all good, but we must not leak JsonElement objects out of the API.