dotnet
Fix for DataContractAttribute evaluation
In my tests the DataContractAttribute could not be found, because Globals.TypeOfDataContractAttribute is a DataContractAttribute with ref. to the Framework Fork. Because this Framework Fork won't be used in "real live" projects, the DataContractAttribute could not be evaluated. To fix this, the code now searches for the same FullName and read the properties via reflection in order to build the DataContractAttribute used by the Framework Fork.
This fix will probably fix, because namespace will now be evaluated correctly #3812
I think you might be able to get a cleaner implementation using GetCustomAttributesData so you don't need to use reflection.
@mconnew You're right, that's slightly nicer. Even if I think that internally the GetCustomAttributesData also uses reflection ;)
It doesn't in quite the same way. There's a class called MetadataLoadContext which enables you to load assemblies in a non-executable way. You can even load assemblies of different versions than are currently loaded and being used in the process. GetCustomAttributes causes the attribute to be instantiated so doesn't work with MetadataLoadContext, but GetCustomAttributesData works fine as it doesn't instantiate an instance. The avoiding of reflection is because you can refer to properties and constructor arguments by name and avoid the reflection there. One thing to keep in mind is you have to check the constructor arguments as well as the properties as it doesn't run the constructor which would normally result in the property getting set.
The DataContractAttribute has no constructor arguments. Please have a look at the code changes where I use the adviced GetCustomAttributesData method. It fixes the bug #3812 and I have no clue how the original implementation ever worked?!
