XObjectsCore references CodeDom

mamift / LinqToXsdCore

LinqToXsd ported to .NET Core (targets .NET Standard 2 for generated code and .NET Core 3.1, .NET 5+ for the code generator CLI tool).

Microsoft Public License

41 stars 15 forks source link

XObjectsCore references CodeDom #24

Closed jods4 closed 3 years ago

jods4 commented 3 years ago

XObjectsCore is a runtime requirement for the code generated by this project.

It feels wrong that it references System.CodeDom, which would be better not embedded into our applications.

Do you think it would be hard to correct the layering and have a CodeDom dependency for the code generation only?

mamift commented 3 years ago

Hello, yes I'm aware of this and did try separating out the C# code that only does code generation to it's own library in an attempt to bring down the .NET Standard version for the output code, but was never able to finish.

I can't specifically recall the reasons why, but I think a few interfaces were shared between the code that handled typed XML traversal and code that does code generation, and a proper & clean split that would've meant 3 libraries instead of just 2.

I thought at the time that was unnecessary, but I'm not philosophically opposed to it if that's what it takes to separate out the code.

jods4 commented 3 years ago

I'm interested in at least giving it a shot, if it doesn't get ridiculously messy.

Is there any list or way to know what classes / public API the generated code actually needs? Or at least some roots and I'll work transitively from that?

Figuring out from the code generator what API might be used in every situation is kind of hard. :(

jods4 commented 3 years ago

I had a glance at the project structure.

So currently we have: LinqToXsd, references XObjectsCore XObjectsCore, references XObjectsCode XObjectsTests references LinqToXsd + XObjectsCore

Looks like the shared code in XObjectsCode is not really shared as only XObjectsCore reference it.

I would try to:

Keep in XObjectsCore what's required by the runtime only, no references to other projects and no reference to CodeDom.
Either merge all the rest directly into LinqToXsd, or turn XObjectsCore into a real lib that could be published on Nuget and is referenced by the CLI project LinqToXsd.

I would not remove any public API, nor rename them nor the namespaces. Just try to move stuff around and do the minimal changes required to cut the dependency on CodeDom from XObjectsCore.

jods4 commented 3 years ago

@mamift Please have a look at #27, removing CodeDom turned out to be not too bad.