Revert back to System.Numerics.BigInteger instead of Org.BouncyCastle.Math.BigInteger about unity-sdk HOT 3 CLOSED

Does the original Nethereum use the real System.Numerics.BigInteger or do they have a customized version? If the Editor post-processor hack works reliably on Windows/Mac/Linux then I'd be in favor of switching to System.Numerics.BigInteger. Is that the only reason we have a Nethereum fork?

from unity-sdk.

The original Nethereum uses the real System.Numerics.BigInteger type, the customized version was made by me. But no, that's not the only reason for the fork - its initial purpose was to change the namespace, so as to avoid conflicts. Also, the fork uses an older version of NewtonSoft.Json, since no AOT-friendly newer versions exists.

I'll do the check on macOS and Linux Unity editors, but generally, the modification is trivial enough to be reliable across the board.

from unity-sdk.

@enlight
Turned out, even though would happily accept the modified project, and it would use an assembly that uses System.Numerics just fine, it would still refuse to compile the code itself, so this approach with hacking the project files isn't working in the end.
However... System.Numerics.dll is just 90 kB, and now I don't see any harm in just including it with the Loom SDK, at least until Unity fixes their bug with System.Numerics not being referenced by default.

from unity-sdk.