Skip to content
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

Open
1 task
mconnew opened this issue Dec 6, 2019 · 2 comments
Assignees
Milestone

Comments

@mconnew
Copy link
Member

mconnew commented Dec 6, 2019

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 use Type.GetCustomAttributesData. XmlSerializer.GenerateSerializer does the bulk of the work so there might need to be changes there as well.

Original issue: dotnet/corefx#41286

  • Port to 3.1.x
@vzalamea
Copy link

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:
Method 'System.Xml.Serialization.XmlSerializer.GenerateSerializer' was not found. This is likely because you are using an older version of the framework. Please update to .NET Core v2.1 or later.

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?

@ericstj
Copy link
Member

ericstj commented Aug 4, 2020

I happened to be looking at this and prototyped a bit ran into more places that use GetCustomAttributes.

object[] obsoleteAttributes = type.GetCustomAttributes(typeof(ObsoleteAttribute), false);

object[] attrs = provider.GetCustomAttributes(false);

object[] attrs = memberInfo.GetCustomAttributes(attrType, false);

object[] attrs = ctor.GetCustomAttributes(typeof(ObsoleteAttribute), false);

All of these were hit by XmlSerializer.Generator. There are other uses that may also be significant, but I stopped after looking at these:
https://github.com/search?q=GetCustomAttributes+repo%3Adotnet%2Fruntime+path%3A%2Fsrc%2Flibraries%2FSystem.Private.Xml%2Fsrc%2FSystem%2FXml&type=Code&ref=advsearch&l=&l=

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.

@HongGit HongGit modified the milestones: 5.0.0, 6.0.0 Aug 25, 2020
@HongGit HongGit assigned HongGit and unassigned mconnew and StephenMolloy Mar 4, 2021
@HongGit HongGit modified the milestones: 6.0.0, 7.0.0 Aug 19, 2021
radical pushed a commit to radical/runtime that referenced this issue Jul 7, 2022
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.
@HongGit HongGit modified the milestones: 7.0.0, 8.0.0 Aug 12, 2022
@HongGit HongGit modified the milestones: 8.0.0, 9.0.0 May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants