-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Microsoft.XmlSerializer.Generator fails to generate serializer for assemblies not targeting netstandard2.0 #630
Comments
I have a netstandard2.0 project with a reference.cs file generated by the Visual Studio WCF web service reference generator. We point the tool to a WSDL to generate the reference.cs file. The project is referenced by a netcoreapp3.1 web application. I gave up on the Microsoft.XmlSerializer.Generator due to the error: So I added the package "dotnet-svcutil.xmlserializer" instead and it successfully created a myproject.XmlSerializers.dll file with all the read/write logic for serialization/deserialization. And I did notice a major reduction in start up time when this file is present in my bin folder. So what is the difference between Microsoft.XmlSerializer.Generator and dotnet-svcutil.xmlserializer? |
I happened to be looking at this and prototyped a bit ran into more places that use GetCustomAttributes.
runtime/src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs Line 101 in 6991ccd
runtime/src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs Line 200 in 6991ccd
All of these were hit by XmlSerializer.Generator. There are other uses that may also be significant, but I stopped after looking at these: Those would all be challenges to porting this code to use MetadataLoadContext. You'd need to fix all of them that are hit by XmlSerializer.Generator, and even once fixed it would limit XmlSerializer.Generatorto only work on the framework version with those fixes. |
Currently, it was very hard to maintain argument definitions because inheritance no longer followed the real world e.g. some commands inheriting but hiding parent members or some commands inheriting commands by mistake such as the web server ones going to almost all commands. This new way allows easier management and re-use of argument definitions across different commands. Arguments are defined, parsed and validated in one place and commands then pick those.
The runtime config for the Microsoft.XmlSerializer.Generator specifies to run on netcoreapp2.0. When reflecting over application assembly to generator serializer, if the assembly is referencing for example NetCoreApp3.0, the version of System.Runtime referenced by the library can't be loaded.
The fix is to change the assembly loading code to use System.Reflection.MetadataLoadContext to reflect over the application assembly. We do use
Type.GetCustomAttributes
at least in sgen.cs so we would also need to make changes to useType.GetCustomAttributesData
. XmlSerializer.GenerateSerializer does the bulk of the work so there might need to be changes there as well.Original issue: dotnet/corefx#41286
The text was updated successfully, but these errors were encountered: