I moved code around so that the CodeDom dependency is removed from XObjectsCore (i.e. the runtime package).
High level changes
Turned XObjectCode into a real C# project, referencing CodeDom. It's referenced by the CLI tool and the tests.
Removed XObjectCode dependency from XObjectsCore, as well as CodeDom.
Moved code around until everything compiled fine again, mostly moving files was enough.
Some stuff was marked internal but is used by both projects. To solve this easily without exposing new members, I added a InternalsVisibleTo attribute on XObjectsCore allowing XObjectCode to use internal stuff.
I think there was one single class that contained code referenced by Core but also using CodeDom. I extracted what Core used into ListFormatter (new file, old code).
Is it good?
This is not well tested but:
I did not change any actual code in this PR.
The project fully compiles with no error and the same warnings as before.
I have taken every generated .cs file from the test Schemas folder and they all compile fine with no reference other than XObjectsCore.
(3) makes me feel pretty confident we've got all the public APIs covered as there's a lot of big xsd in there. That said, there could be a rare public API that was left in XObjectsCode (which would be detected at compilation time for any affected user).
Further improvements
I deliberately made no attempt at cleaning up the code (as diffs would be hard to review with so many moves).
The layering is very crude and could be better with more efforts. There's a lot of stuff left in XObjectsCore that's actually only used by XObjectsCode. At least the external CodeDom dependency is gone and I think it's a good first step.
Fixes #24
I moved code around so that the CodeDom dependency is removed from XObjectsCore (i.e. the runtime package).
High level changes
InternalsVisibleToattribute on XObjectsCore allowing XObjectCode to use internal stuff.ListFormatter(new file, old code).Is it good?
This is not well tested but:
Schemasfolder and they all compile fine with no reference other than XObjectsCore.(3) makes me feel pretty confident we've got all the public APIs covered as there's a lot of big xsd in there. That said, there could be a rare public API that was left in XObjectsCode (which would be detected at compilation time for any affected user).
Further improvements
I deliberately made no attempt at cleaning up the code (as diffs would be hard to review with so many moves).
The layering is very crude and could be better with more efforts. There's a lot of stuff left in XObjectsCore that's actually only used by XObjectsCode. At least the external CodeDom dependency is gone and I think it's a good first step.