Open justinoverton opened 4 years ago
Sounds like a neat idea; but if you do decide to implement this I strongly recommend that you implement it via post-processing the generated code, so use Roslyn transformations on the return TextWriter
instance given by the Generate(XmlSchemaSet schemaSet, LinqToXsdSettings settings)
method in the XObjectsCoreGenerator
class.
The existing code base for generating code from an XSD is so very convoluted and written in a now 13-year old style that it's hard to bug fix and re-factor. Fixing that enum issue for instance took quite a while.
After the enum generation is completed I would be willing to make this change.
I have to work with XML files provided by vendors that define the enumeration restriction for fields that change somewhat often. This issue is what lead me to find LinqToXsdCore. When an xml enumeration is compiled into a .net enum, it cannot handle XML that comes across with a different value than specified in the schema.
Semantically, the schema says it is invalid. Treating enums as strings solves this, but the reality is that the generated enums are really helpful when producing input to a vendor. They may be useful when consuming a document, but also may never be looked at again.
I like LinqToXsdCore because I can load a document, look at only the sections I need, and save it. If the vendor added entirely new elements without telling me, it works fine in the round-trip.
I can't be the only one that's had this kind of issue with the strict enums and vendor controlled formats. I thought it might be worth while to look into a flexible enumeration strategy instead of compiled enums.
See: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/enumeration-classes-over-enum-types
This defines a Enumeration that is integral with a name (just like regular enums), but for many XML restrictions it probably doesn't even need the integral part.
Code snippets from the above link:
I was thinking about just post-processing the code dom. But after looking into the get/set accessors I decided if I can get this feature to be properly supported in this library that would be much easier.