Runtime: 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

[SamuelEnglard]

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.

[SamuelEnglard]

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

[danmosemsft]

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

[danmosemsft]

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

[SamuelEnglard]

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