Dictionary serialization incorrect when publishing to single file

[prettyv]

Dictionary serialization incorrect when publishing to single file

[prettyv]

I can't say I fully understand the context around the code in question, but as a minimal change wouldn't it be sufficient to change the logic from checking the memberInfo.Module.Name to memberInfo.Assembly.GetName().Name? That should give pretty much the same strings to test against, only without the .dll extension, if I'm understanding the code right. Reading from the assembly name would have no issues with single file publishing.

[axunonb]

Hi,
That sounds really weird. The v3.0.1 unit tests under Windows and Linux were successful and I don't have your environment at hand.
However, this effect can be reproduced on Windows and Linux, if ReflectionUtils.IsPartOfNetFx(MemberInfo memberInfo) retunrs false.
Could you please check the value of any system type's module name, like typeof(string).Module.Name. It's expected to be System.Private.CoreLib.dll for netstandard2.0.
@NKnusperer Didn't you mention some time ago an issue with this kind of preprocessor directive?

[prettyv]

Interesting, typeof(string).Module.Name returns <Unknown> when publishing as a single file app. This is also true when publishing for a linux target, seems like I might not have tested what I thought to have tested when reporting.

I get this warning when publishing for a target with a clean cache:

warning IL3002: Using member 'System.Reflection.Module.Name' which has 'RequiresAssemblyFilesAttribute' can break functionality when embedded in a single-file app. Returns <Unknown> for modules with no file path.

I don't quite know what to make of this yet.

[axunonb]

warning IL3002: Using member 'System.Reflection.Module.Name' which has 'RequiresAssemblyFilesAttribute' can break functionality when embedded in a single-file app. Returns for modules with no file path.

At least we know the reason for this issue. Btw: System.Reflection.Module.Name is used only at this place in YAXLib.
@prettyv: Not sure yet, if checking System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription would be a useful alternative to System.Reflection.Module.Name, as it could return null.