I've been organizing my dependencies for @xunit v3 so I can minimize them (anything that doesn't ship in .NET itself is a potential compatibility clash with library versions that developers want to use).
I'm not that worried about System.Collections.Immutable or IAsyncDisposable having breaking changes across major versions. System.Text.Json, on the other hand, feels like potential danger territory. The alternative of writing even a very feature-limited JSON parser makes me uncomfortable.
This problem is much worse in v2 because you build DLLs not EXEs, so there's no compiler to help resolve dependencies between us and your tests. App domains help in .NET Framework, but aren't available on .NET Core/.NET.
Even with the eased restrictions, I'm still a little nervous about it. We had to stop using JSON.NET because the author of JSON.NET wanted to test JSON.NET with xUnit.net and couldn't, because our old version "won" in the loading lottery.
Our solution at the time was that we nicked this code from very early .NET Core (maybe even back when it was called Project K, as I think they were using it for parsing the old JSON-based project files before they reverted back to using MSBuild). https://github.com/xunit/xunit/blob/v2/src/common/Json.cs
I don't have a problem doing my own serialization. It doesn't have to be an open ended problem, and the wire format of JSON is quite simple. Generating legal JSON is an order of magnitude (or more) simpler than parsing it.
@bradwilson Would some kind of DLL embedding or IL merging work here? I remember doing that in Framework days for a library, but that tooling doesn't work now. Searching around, there seem to be some potential options, e.g. https://github.com/CCob/dnMerge
@Josh_Gallagher We use ILRepack for executables. Generally repacking things changes their identity, but in this case changing the identity of System.Text.Json's types probably isn't a big issue. It's something to consider.
Add comment