@matthid is this associated with any particular known issue?

@denfromufa I did not find anything

Note for someone hit by this: In my situation a workaround was to mark the class as internal, as there was no need for it to be exposed...

Not sure if its the best fix as there now we potentially have uninitialized instances floating around at the place I marked with a comment.

However a "better" fix would need to consider this (edge-)case from the start and would need drastic changes...

@matthid can you provide this edge case as a test?

Also I think the test should be formatted something like a node class and its child as subclass, otherwise it is confusing why would people ever need recursive types like this. So the use case is for trees and graphs?

@denfromufa not sure I understand. I already added a testcase.
I'm wondering why the use case matters.

Anyway I tried to explain that the F# compiler generates classes like these for discriminated unions. And I have from time to time written such constructs myself (for exactly the same concept in C#).

Problem is that I had the stack overflow in a class I was not even using in interop (this is due the fact how the F# compiler organizes code)

Hope that helps.

To clarify: The "recursive" class was not even used in the interop and I still got this error because it was part of a F# module (which will be translated to a static class)...

Just let me know if there is still something missing in this PR.
@denfromufa If I should refactor the test classes can you please suggest the names I should use? Thank you

@matthid are there any known side-effects of "...we potentially have uninitialized instances floating around..."?

@denfromufa Not that I'm aware of. On the other hand this case is tested with the unit test. It's just that it "feels" a little bit unclean.

Ok, then let's check what @tonyroberts @filmor @vmuriart think, and then we should be able to merge!

From my side this looks fine.