XObjectsCore references CodeDom about linqtoxsdcore HOT 4 CLOSED

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.

from linqtoxsdcore.

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. :(

from linqtoxsdcore.

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.

from linqtoxsdcore.

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

from linqtoxsdcore.