mamift
commented
3 years ago I've never been able to work with the nullable reference types feature of C# 8, so I have no strong opinion on it either way, but I welcome suggestions to improve the code generation so as to better keep up to date with the latest C# language versions.
I think this would need to be behind a command-line argument, because unsupported syntax or preprocessor directives would surface in older compiler version.
Yes, definitely agree here as the generated code is .NET Standard 2.0-compatible and I would like to keep this as the default option for generating code. XML data processing is itself a legacy problem that is encountered much less and less nowadays.
The easy short-term support is to add #nullable disable at the top of generated files.
Yes, this should be an easy implementation using Roslyn.
If possible, it would be awesome to have proper nullable annotations instead. You have all the required metadata for that and already do the work for value types. Reference types that are optional or part of a choice should be nullable.
Proper annotations support might be a too big an ask for a project with this much legacy code. The code generation logic uses CodeDOM, and it was only ported to .NET Core and is not actively improved with new features or bug fixes. From memory, CodeDOM only supports generating C# 3 code (pre-dates things like async and dynamic keywords).
Since nullable reference types extend the language syntax (letting ? be suffixed to reference type names, like string? or object?), it would require a Roslyn transformation on the syntax tree generated by CodeDOM as CodeDOM itself would have no awareness of what nullable ref-types are.
But using Roslyn to transform the generated syntax tree means losing out on all the internally generated metadata and property information that is used by the schema processor to create the CodeDOM graph. Putting attributes in the right place, placing the ? question mark on the right type names I imagine would be a huge undertaking to get it right. Based on my own readings and understanding of the code base as it is, I believe it would be akin to having to re-infer that metadata a second time by deconstructing schema semantics from the generated code.
Love to be proven wrong though; this is just my initial analysis on the work required for such a change.
jods4
It's so good that you are carrying on this project, thanks! It is so much better than xsd.exe.
Now that C# has nullable references, do you think that you could add some support?
I think this would need to be behind a command-line argument, because unsupported syntax or preprocessor directives would surface in older compiler version.
The easy short-term support is to add
#nullable disableat the top of generated files. This instructs the compiler that code inside this file is unaware of nullable references. It avoids issues when the generated C# file is included in a project that is null-aware by default.If possible, it would be awesome to have proper nullable annotations instead. You have all the required metadata for that and already do the work for value types. Reference types that are optional or part of a choice should be nullable.
Short discussion about the correctness of those annotations
Nullable references are tricky, esp. on complex types that can be built up. A balance must be achieved between usefulness and correctness.
When an xml file conform to its xsd is read, the annotations are exact. If not, I think one can accept incorrect nullable annotations on invalid data (garbage in -> garbage out).
LinqToXsd also allows the creation / writing of xml files. This is more complicated since during construction the xml might not be valid. A required attribute will be null until the code sets its value.
I argue that it's more useful to have the annotation:
Again, this is assuming that linqtoxsd doesn't throw when reading a value that wasn't set (which would make this discussion useless).