Modify the LinqToXsd program such that it will emit one xml namespace to one corresponding c# file. about linqtoxsdcore HOT 13 OPEN

I am reaching out in hopes that you will be willing to work with us to get LinqToXsd to 100% operational.
I have created something of a playground to experiment in. Attached is a zip file that contains the XSD_Working directory, which contains the AZ State Supreme Court xsd set (I'm required to state that all material is copyrighted by their respective owners and that none of the material contained within the zip file is eligible for remuneration of any form - in short, you can't sell it. The specs are open source so you can share them, just not receive compensation for them.)
The AOC.ECF project has both the working code and the corresponding unit tests (written in NOT my language of VB - I inherited this project from someone else, I'm a C# guy). The generated code can be found in the AOC.eFiling.ecf.exchange directory, the corresponding .config file is found in XSD_Workspace under xsd_2_1\xsd\exchange\2.1\AOC.eFiling.exchange.2.1.xsd.config - the others are the raw form as generated with the -o option, the added namespaces are added because LinqToXsd didn't pick them up for whatever reason.
The folks at the AoC (Administrative Office of the Courts) are very interested in getting this tool of yours working 100% as we will be using it for the foreseeable future to generate our c# classes.
Please feel free to reach out with any questions or modification requests, my only job at the moment is to get this up and running for the courts.
Thanks!
XSDWorkingCode.zip

from linqtoxsdcore.

Saw the new code. Downloaded and applied to the XSD_Workspace provided in the zip file attached above.
The new config file is:

The command used to generate the above config is:
\LinqToXsd config -e C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2\AOC.eFiling.ecf.exchange.2.2.xsd -o C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2\AOC.eFiling.ecf.exchange.2.2.xsd.config

The result is:
Workspace Root = C:\Users\sam\Documents\XSD_Workspace
Workspace Target = C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd
Config Target = C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2
Source XSD = C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2\AOC.eFiling.ecf.exchange.2.2.xsd
Source Config = C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2\AOC.eFiling.ecf.exchange.2.2.xsd.config
Output Dir = C:\Users\sam\Documents\src\AOC.ECF\src\AOC.eFiling.ecf.exchange
Generate command is: C:\Users\sam\Documents\src\LinqToXsdCore\LinqToXsd\bin\Release\netcoreapp3.1\publish\LinqToXsd gen C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2\AOC.eFiling.ecf.exchange.2.2.xsd -e -c C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2\AOC.eFiling.ecf.exchange.2.2.xsd.config -o C:\Users\sam\Documents\src\AOC.ECF\src\AOC.eFiling.ecf.exchange
Configuration file(s) loaded...
Outputting 1 files... C:\Users\sam\Documents\XSD_Workspace\xsd_2_2\xsd\exchange\2.2\AOC.eFiling.ecf.exchange.2.2.xsd => C:\Users\sam\Documents\src\AOC.ECF\src\AOC.eFiling.ecf.exchange\AOC.eFiling.ecf.exchange.2.2.xsd.cs

In short, it still generates a single file. Am I missing something?

from linqtoxsdcore.

Hi sorry, I have not yet wired up the new source-splitting functionality to the command line interface.
My bad for not contributing to a separate branch. I'll comment again on this issue when the functionality is complete.

from linqtoxsdcore.

Hello,

Yes such a feature is something I myself have wanted more than a few times now. I'll see what I can do.

Just out of curiosity, are you able to share the XSD files that you're using?
I've been trying to collect a bunch of XSD files for use in the testing library, as due to the lack of unit tests, I have to resort to writing a bunch of integration tests that cover the source code generation code. More XSD files means more coverage.

from linqtoxsdcore.

from linqtoxsdcore.

I have been granted permission to share! Perhaps we can work together to fix all of the issues that are cropping up in the result. What I'll be supplying shortly is the entire Arizona courts electronic filing specification. It's not small, you will probably need an additional editor to handle the file - my VS just crashes if I ask hardly anything of it. 2022 can handle the file but even it is slow. I'll send an update when I have the spec in GitHub - I'll invite you as a contributor.
Thanks for stepping up!

from linqtoxsdcore.

@chiefengineer - just a suggestion of a workaround for your case. In my project we also use quite a complex xml data schema, and a generated file is quite large.

What we do to work with it is we generate a cs file with LinqToXsd tool, and then we build it using msbuild tools. Then we use the resulting assembly which contains all generated classes in the projects that consume the object model.

This way Visual Studio doesn't need to digest a huge source file.

Please let me know if you need any details or help. Thanks.

from linqtoxsdcore.

@auliere - Sure, but what if the generated code has errors (which ours does)? You need an environment that is intelligent enough to assist in dealing with the errors and provide at least some guidance as to a solution to whatever the problem is.
No matter though, I can compile the generated code (barely) in VS 2019 as long as I don't need to modify it - at all. VS 2022 seems to work OK with the file but I can't use a preview tool for production for a number of reasons.
It's OK, though, I have a work around that I'm building that will "get us by" until the LinqToXsd program can be modified. I'll post it here once I'm done with it. Basically waiting for mamift to respond so we can take the next step.
Thanks for the suggest though, it's nice to know the community is out there thinking about this stuff.

from linqtoxsdcore.

@chiefengineer Thank you for your response!

The part about the errors in the generated code is quite interesting. Can you provide an example? Maybe it is these errors that need a fix in the first place.

Edit: I looked at the archive you provided and found the error examples there.

from linqtoxsdcore.

@chiefengineer the changes to the tool don't seem to be trivial. I've created a script to break up a large file based on namespaces:
https://gist.github.com/auliere/5f1c8feeb4717bbea69d1863ac3b444f

It is quite slow, but it works...

from linqtoxsdcore.

@auliere - Glad you found the file, it was what I was going to refer you to. Those are the items that needed manual attention before the resulting generated file compiles. Thanks for creating the script, I am in the process of creating a program to do the same thing - split the one file up on c# namespace. It'll do until the code can be adjusted appropriately. And you're right - the code changes to LinqToXsd are not in the least "trivial". I'd tackle it but my organization has, so far, forbade me from doing so - they would rather the original author fix it.

from linqtoxsdcore.

No worries, figured it was something like that. I'll keep an eye out.

from linqtoxsdcore.

Hi @mamift.
I have a multiple schemas that import a single shared schema.

Is there any way to generate code for that?
Currently every schema includes the shared schema code in its C# file so there are lots of conflicts.
It looks like <SplitCodeFiles By="Namespace"> doesn't seem implemented, so I think that I'm out of options?

An option to not generated imported schemas code would be enough (as I can generate them once separately).

from linqtoxsdcore.