Port xsd.exe to .NET Core

[hrushib]

We use xsd.exe to generate C# classes for based on xml schema. At present there is no xsd.exe tool to generate CoreCLR compliant code and hence code generation can not be fully automated as part of the build at the moment.

Please let us know plan/timelines around availability of the same.

[joshfree]

Related tracking issue for XmlSchema in CoreFX https://github.com/dotnet/corefx/issues/2342

/cc @piotrpMSFT @krwq @sepidehMS

[shmuelie]

The code XSD.exe generates is pretty much .NET Core safe, at least in my usage. What have you seen that's not usable?

[krwq]

@SamuelEnglard, AFAIK there are couple of attributes which do not exist on .NET Core which makes automating the tool harder.

@hrushib, currently I'd just add the missing attributes and treat them as no-ops so that your generated code compiles - it won't be ideal solution but should unblock you for now.

Our current plan is to bring XmlSchema back first and then proceed from there. Unfortunately I can't give you any specifics at this time :-( We currently did not have any prior requests for xsd.exe so we put it on our backlog. It's really valuable feedback to know that this is needed and being actively used as part of the build.

[shmuelie]

@krwq Very possible. I am using it as far as feedback that it's in use 😄

[danmoseley]

Now we have CodeDOM we do want to take a look at this for 1.2. Not immediately though.

[danmoseley]

@weshaggard if we did this, how would we ship the exe? would it have to go in the shared framework?

[shmuelie]

why not make it part of dotnet tooling?

[weshaggard]

@weshaggard if we did this, how would we ship the exe?

The majority of the tools are part of the SDK or CLI so I would expect it to ship in one of those 2 places.

[Jonathan34]

I also need XmlCodeExporter to be ported to .net core (2.0). Any ETA or workaround for that? This is mostly what I use.

exporter.GetType().GetProperty
exporter.ExportTypeMapping

System.Xml.Serialization.XmlCodeExporter does not exist in .net core.

[fletchsod-developer]

The milestone said future.

For people who been stuck 2 years and still counting. This might help but it's all in .NET framework, not .NET Core.

http://mikehadlow.blogspot.com/2007/01/writing-your-own-xsdexe.html https://github.com/codaxy/xsd2

[HakanL]

Not sure if this is the right place for this comment, but I have a huge xsd-generated CS file (out of all of Amazon's XSDs). It compiles fine, but when I try to serialize an object using XmlSerializer then I get a PlatformNotSupportedException, saying it can't generate the temporary assemblies. This is on .NET Core 2.0. I bet something is up with the generated CS file, if I copy relevant parts out to a new file and use that then it works fine. Can it be due to the size of the classes, or what would trigger the XmlSerializer to try to build a temporary assembly?

[sbergen]

I would like to be able to build a customizable XSD to C# converter, and looking at the latest recommendations, I should be using XsdDataContractImporter (together with XmlSchemaSet and CSharpCodeProvider), which is not available.

[ghost]

on Oct 11, 2016 Not immediately though.

Does it mean NEVER or sometime after 2029? Please SHIP the stuff if it isn't a rocket science and doesn't require more than few hours of work. Delaying this kind of petty stuff is only letting down folks who are actually using the product, "Not immediately" even from majority's use-case doesn't explain the intensity of of hundreds of other use-cases that are relying on xsd.exe.

Will it be a dontet-cli tool?

[hrushib]

@weshaggard, @danmosemsft what is present recommendation for generating C# classes based on xml schema for CoreCLR projects built on Linux?

[meixger]

@hrushib I'm using https://github.com/mganss/XmlSchemaClassGenerator successfully.

[krwq]

@hrushib if you're doing it in automated way then we do not have any way to do that, if you're planning to generate and modify it by hand you can generate them on full framework on Windows and with minimal modification they should be usable.

[hrushib]

@krwq, I am looking forward for automation as this is expected to happen with build. We are waiting for this support for almost couple of years now. Absence of this support is pushing us to use workaround of manual updation of this file using xsd.exe and checkin for builds triggered on Linux, as full framework tool can't be used there :(.

Can you provide plans/timelines for this feature to be available on CoreCLR?

[ghost]

dotnet-xscgen is released from https://github.com/mganss/XmlSchemaClassGenerator, you can reference it in your netcoreapp2.0 project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="dotnet-xscgen" Version="2.0.*" />
  </ItemGroup>
</Project>

and then run it as dotnet xscgen --help in the project directory.

With dotnet 2.1's CLI, we will also be able to install it as standalone app (outside the project context): dotnet tool install dotnet-xscgen --tool-path MyTools then use it as MyTools/dotnet-xscgen.exe --help or dotnet tool install dotnet-xscgen --global and use it as dotnet xscgen --help.

[krwq]

@hrushib we currently do not have plans for xsd.exe

[fletchsod-developer]

Does the dotnet-xscgen read in the C# model and validate the data dynamically inside the C# script instead?

If not then what DotNetCore component should I be looking for that does this with XML Schema Set, XmlReader, XmlReaderSetting, etc. stuff for this kind of XML Schema validation?

[krwq]

cc: @zhenlan who's team owns the xsd.exe

[TonyHenrique]

Also XSD.exe on .NET Core needs to support F# Code generation, better C# enums, better code generation.

https://developercommunity.visualstudio.com/idea/426740/better-xsd-xml-tooling.html

This is very important. Please consider this, because it is becoming really critical to have a better XSD -> XML support. Too many governament services rely on messaging via XSD/XML, and this is becoming very complex to tackle with current XSD.exe tool. Also we need XSD.exe to support F# code generation.

With this generated code classes (C#, F#) from the XSD we can then use, for example, Azure Functions to process this XSD->XML and send requested data to goverment servers.

In Brazil, for example, billions of transactions are using this, by millions of companies (from small to bigger ones). A sample complex XSD schema: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=ZT5UvIuQ4N4=

[krwq]

cc: @Lxiamail

[StephenBonikowsky]

Some investigation is needed first to determine the scope of the work.

[Rubbiroid]

Is there any news or plans? We also need this to be able to migrate to core 3. Banks still love xsd...

[StephenBonikowsky]

We haven't been able to look at this yet. We have several items in the Serialization area that we are looking into for either 5.0 or 3.1 Servicing.

[StephenBonikowsky]

Increasing the priority for this task.

[theRainbird]

I need to create typed DataSet code, because I'm planning to port a very large ERP application (over 1 million lines of code) to .NET Core, which massively uses typed DataSets. Without xsd.exe or another way to create type DataSet code, a port is not possible.

[mv10-work]

@theRainbird With all due respect, I hope they do not implement DataSet support, it's a very outdated model. I just finished migrating a huge, messy legacy application off DataSet to more sensible generics and LINQ, so I sympathize with you, but from what I've seen, that pain-point hasn't been a convincing argument for adding old-world features to modern .NET. (If they do implement it, I hope they finally fix the atrocious DBNull exception mess introduced way back in the .NET 2.0 release.)

[wilfriedb]

TL;DR: I'm trying to get xsd.exe to run under .NET 6.0. As a prerequisite, I've made some changes to XML.Serialization. Am I heading in the right way?

Because our team also has a need for for xsd.exe (or a similar tool) I went looking what is needed to revive xsd.exe. I found the source code on ReferenceSource, and tried to build it against .NET Core 5.0. This didn't work because one type was missing: XmlCodeExporter. So I forked dotnet/runtime and copied the missing type from .NET 4.8 into it. Of course, this caused a small cascade of other missing types, and I added them as well. After adding a lot of nullable annotations and null checks I now have a version of XML.Serialization that builds with these old/new types included.

My work so far: XmlCodeExporter add

There's still some work to be done: I couldn't find the resource strings in ReferenceSource (maybe someone else can find them), unit tests need to be added, and the coding style of the copied code is really old fashioned, maybe that could be cleaned up as well.

Before I spend more time in this effort, Is this modification (actually, just re-adding some classes) something that the .NET team will be going to accept a pull request for? Or has the team an other solution in mind?

I would love to hear from you.

[danmoseley]

@HongGit

[theRainbird]

@mv10-work

With all due respect, I hope they do not implement DataSet support, it's a very outdated model.

Nobody forces you to use this old school stuff. But if you have to migrate a large application with over a million lines of code to .NET 5+, it is very bad if you have to write everything from scratch.

[davidxavier77]

Hi, dotnet core 6.0 is out. Is it in or out ?

[StephenMolloy]

As @wilfriedb points out above, the source code for xsd.exe in the .Net Framework is open sourced. If anyone wants to take a stab at a .Net Core implementation, our team is unable to prioritize this at this time.

[danmoseley]

I couldn't find the resource strings in ReferenceSource (maybe someone else can find them),

https://github.com/microsoft/referencesource/blob/master/xsd/XsdRes.txt

coding style of the copied code is really old fashioned,

As you can probably imagine, that's quite typical of the C# written around .NET 1.0, 20 years ago now. 🙂 The style you see in .NET Core repos was cleaned up substantially when the project began.

[sanghel-payoff]

... maybe the kind soul that tackles this will eventually fix https://github.com/dotnet/wcf/issues/1274 also

[jinek]

Second option is to use mono xsd tool

[deeprobin]

Is it at all still relevant to have a tool like xsd.exe which exports the code to files?

That would be a good use case for a source generator imo (indicated by a XsdGeneratorAttribute),

[Lancelotbronner]

I still like the idea of a CLI tool to work with xsd, I'll try and modernize it but if it needs to touch the runtime then I don't think I'll be able to do much.

[LevYas]

@deeprobin

Is it at all still relevant to have a tool like xsd.exe which exports the code to files?

Sure, almost all the XSD I had were not 100% correct, I had to modify the resulting classes to make them actually work with the third-party APIs. From a tool like xsd.exe, I expect to produce compact and readable code, which I can reason about and modify if needed.

[soroshsabz]

ITNOA

Any update? does XSD.exe source code available?

[soroshsabz]

Ok I found it https://github.com/microsoft/referencesource/tree/master/xsd

:D

[nalinasanka]

Hi All,

I was able to generate XSD file for .Net Core library using below code. If anyone is keen to generate xsd file for .Net Core instead of using "xsd.exe", hope this code will be handy.

try
{
    XmlSchemas schemas = new XmlSchemas();
    XmlSchemaExporter exporter = new XmlSchemaExporter(schemas);

    XmlTypeMapping mapping = new XmlReflectionImporter().ImportTypeMapping(typeof("Your Class Name"));
    exporter.ExportTypeMapping(mapping);

    using (TextWriter writer = new StreamWriter("output.xsd"))
    {
        foreach (XmlSchema schema in schemas)
        {
            schema.Write(writer);
        }
    }

    Console.WriteLine("XSD generated successfully.");
}
catch (Exception ex)
{
    Console.WriteLine($"Error in generating XSD. Error: {ex.Message}");
}

"Your Class Name" --> Needs to replace with your class name which you want to generate XSD schema.

Thanks