search

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
43 stars 15 forks source link

Modify the LinqToXsd program such that it will emit one xml namespace to one corresponding c# file. #32

Open chiefengineer opened 3 years ago

chiefengineer commented 3 years ago

I have an xsd schema set that, when LinqToXsd is executed against the xsd schema set, generates a file that is over 803,000 lines in length. No, I can make it smaller, this is for handling court information. Unfortunately, LinqToXsd can generate the file, but Visual Studio in it's current production iteration cannot handle the resulting near 30M file. VS crashes routinely. Easy fix - generate a single c# file for each xml namespace. In my case this would result in about 40 files, all of which would be handled by VS easily. Something like a -m switch would be perfect. Otherwise - awesome tool! Saved me a bunch of work!

mamift commented 3 years ago

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.

chiefengineer commented 3 years ago

I will ask.

On Wed, Jun 23, 2021, 16:25 Muhamamd Miftah @.***> wrote:

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 https://github.com/mamift/LinqToXsdCore/tree/master/XObjectsTests, 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.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mamift/LinqToXsdCore/issues/32#issuecomment-867222303, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6A44PXGXPRLFJKEBNT4DDTUJUQLANCNFSM47GR5FXA .

chiefengineer commented 3 years ago

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!

chiefengineer commented 3 years ago

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

auliere commented 3 years ago

@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.

chiefengineer commented 3 years ago

@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.

auliere commented 3 years ago

@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.

auliere commented 3 years ago

@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...

chiefengineer commented 3 years ago

@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.

chiefengineer commented 3 years ago

Saw the new code. Downloaded and applied to the XSD_Workspace provided in the zip file attached above. The new config file is: <?xml version="1.0" encoding="utf-8"?>

false

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?

mamift commented 3 years ago

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.

chiefengineer commented 3 years ago

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

jods4 commented 1 year ago

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).