Runtime: Pre-generated serializers using sgen.exe

[mehuljvora]

Hello,

We currently use pre-generated XMLSerializers generated by sgen.exe to boost the startup time, but these serializers are not available in CoreCLR. Is there any plan to include these serializers into CoreCLR? Or is there any modified version of sgen.exe which generates the CoreCLR compliant assembly?

Thanks,
Mehul.

[zhenlan]

XMLSerializer _is_ supported in .NET Core (aka. CoreCLR).

The pre-generated XMLSerializers by the full .NET tool sgen.exe can only work for applications/libraries built on full .NET Framework.

We have been looking into this but there is no tool available currently that can pre-generate CoreCLR compatible serializers. This is currently also blocked by the fact that .NET Core is lack of a way to persist IL to disk (issue dotnet/coreclr#1709).

Thanks @mehuljvora for the feedback. If other people here have similar needs, we would also like to hear from you. This will be helpful data points for our planning.

[kgabedell]

Hi,

I wanted to share the scenario I am working with, it consists of using VMware's vSphere Web Services SDK (soap).

I have successfully generated the code based off the wsdl using the svcutil.exe contained in the "WCF Connected Service Visual Studio Extension Preview for ASP.NET 5 Projects".

The generated proxy file is large, 81,651k consisting of many proxy classes. The initial class seems to take a very long time to instantiate. Previously in .NET this was solved by using sgen to generate a serializer assembly.

Further information on the scenario and solution can be viewed at:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=87402

https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.wssdk.dsg.doc_50%2Fsdk_c_sharp_development.5.4.html

Please let me know if you need any further information regarding this scenario.

Thanks,
Ken

[atanasa]

@zhenlan, is it possible instead of waiting for a new generator and IL persistence, to make the code that was generated using sgen.exe or svcutil.exe compile under .Net Core?

[masaeedu]

+1 for this. I happen to have exactly the same use case as @kgabedell, and it takes a good 30 seconds for my client to warm up. Many third party services are very large, so it is going to be difficult to use the .NET Core WCF clients in production until there is a good story for pregenerating serializers/deserializers.

[sei-jmattson]

+1. Same case. The jit compilation of serializers might not be too big a problem in production, but it makes development painful (i.e. restarting the application very often).

[zhenlan]

@atanasa, thanks for the suggestion. Unfortunately, CodeDom is not supported on .NET Core either (tracked by dotnet/corefx#9485).

@masaeedu thanks for sharing your scenario. I think you will need a .NET Core version of svcutil tool (instead of sgen), but it will be blocked by the issue dotnet/coreclr#1709 too.

@sei-jmattson, understood - this is all about start-up performance. Thank you for the feedback.

[atanasa]

@zhenlan My requirement is only for WCF to consume the serializer. That is, to have the code generated by svcutil be used by a WCF client. Should I file a separate issue for that case?

[masaeedu]

@zhenlan I've already managed to clean up the output from svcutil to remove System.Web references, and the project compiled and ran correctly on .NET Core, just extremely slowly.

[kgabedell]

@zhenlan I am in exactly the situation as @masaeedu. The performance makes it pretty much unusable at this time going against any large service.

[zhenlan]

@atanasa, yes, please open a separate issue to track the need for svcutil (in github.com/dotnet/wcf repo). Thanks!

@masaeedu @kgabedell, if you can share a repo, we may be able to see if there is anything else we can assist here in terms performance (cc: @mconnew).

[masaeedu]

@zhenlan Is sgen still on the roadmap? Again, this feature is basically useless for real-world services of any size unless we can get rid of the serialization overhead.

[zhenlan]

@masaeedu we are not working on this currently because we don't really have a good solution yet while there are a few other serialization related hot issues/features we can make progress. However, this is on our roadmap and you made it clear how important this is to you. We plan to spend more time and look into alternative solutions. I will share more when I have something.

[jherbert]

@zhenlan Looks like there has been some work going in for this in the last couple weeks. If you need anyone to do some testing (when it comes to that point) I would be happy to help. This will make a huge difference in startup performance for me. Today it's around 60 seconds to generate the XmlSerilizers at run time (very big SOAP/WSDL).

[zhenlan]

Thank you @jherbert! Yes, we put together an initial prototype at below and managed to avoid using CodeDom.
https://github.com/dotnet/corefx/tree/master/src/Microsoft.XmlSerializer.Generator

We are still working on user experience. Current thinking is something like
dotnet Microsoft.XmlSerializer.Generator [UserAssembly.dll and other parameters]
It will generate a cs file and then we will compile it to an assembly that can be loaded at runtime. Any feedback or ideas are welcome! Once we hash this out, we will share the instructions and would love to see how it works for you.

Please note, Microsoft.XmlSerializer.Generator corresponds to sgen.exe on full framework. It has no knowledge of WCF, but it will be the foundation based on which we can build svcutil in the next stage (svcutil will use M.S.G as a library).

cc: @huanwu

[shmao]

We just released a preview of the Microsoft.XmlSerializer.Generator package. Please see the announcement for more information. Here's the instructions on using the package.

Please feel free to leave comments in dotnet/corefx#25138 if you have any feedback. We are actively looking to improve the tool and your input would be very appreciated.