For discussion purposes:

[steinbitglis]

These are some of the changes for the Unity version of the library.
ExampleRunner.cs has been added to enable running of the examples.
'ValidatingDuringDeserialization.cs' has been skipped since I didn't find out how to address the dependencies.

Consider if you want to include any of these changes. I'm maintaining a difference between the code bases for Unity users, for convenience, but of course I want to keep it as small as possible. In my package I don't want to require the 'UNITY' define flag either, so the package has a few additional changes compared to this.

[aaubry]

Thanks, I'll try to merge them as best as possible. Ideally, you should not need to maintain different code for unity. I'll look at this during this week-end.

[aaubry]

Removing the dependency from xunit is a problem for the samples, because I use xunit to execute them. I could use something different, but I already have stuff built on top of that.

It seems that Unity specifies a set of #defines. Maybe we could take advantage of that? For example, if the unity-specific tweaks are wrapped inside #ifdef UNITY_5, it should be easier to merge these changes in the main code. What do you think?

[aaubry]

I've merged the "easy" changes, that don't cause conflicts, to let us focus on the hard ones.

[aaubry]

Does the ambiguity arises from the constructors that take params arrays ?
If so, a workaround could be to change their signatures to:

public YamlMappingNode(
    KeyValuePair<YamlNode, YamlNode> firstChild,
    params KeyValuePair<YamlNode, YamlNode>[] otherChildren
)

This would probably remove the ambiguity.

[steinbitglis]

This should catch 99.9% of the installations, I think,
#if UNITY_3_5 || UNITY_4_0 || UNITY_4_1 || UNITY_4_2 || UNITY_4_3 || UNITY_4_5 || UNITY_4_6 || UNITY_4_7 || UNITY_5

It's big, and it's not future proof, so that's why I edited the code maunally. Maybe I could just write a tool to do it for me or something.

I don't know how far back it actually works though, but we used YamlDotNet way back in Unity 3. YamlDotNet had to be fixed a lot before we could use it etc. but that's another old story.

I wrote my own loop to execute the tests from within Unity, but yes, we could use the defines to use both approaches.

The following seemed to resolve the ambiguity, as you predicted.
0001-Added-suggested-change-to-YamlMappingNode-legacy-com.patch

[steinbitglis]

Here'se ExampleRunner.cs, that I'm using to expose the examples in the unity package, not depending on xunit. (Sorry about the Unity specific stuff mixed in there.)

ExampleRunner.cs
SampleAttribute.cs
TestOutputHelpersExtensions.cs

[EdwardCooke]

This PR appears to be abandoned, it's nearly 5 years old. I'm going to close it.