search

jbevain / mono.reflection

Some useful reflection helpers, including an IL disassembler.
150 stars 50 forks source link

GetBackingField() extension method fails when being run by code coverage report #20

Closed justincook-amcom closed 3 years ago

justincook-amcom commented 3 years ago

This is a very strange issue for sure, but I wanted to reach out and see if you had any ideas.

I am using the GetBackingField extension in a project that can store collections of objects using Excel xlsx files and materialize the same classes from saved xlsx files. One of the design goals was to avoid forcing consumers to declare public setters in order to load from xlsx files. I found your library extremely helpful in resolving the backing fields for Automatic Properties.

I wanted to get an idea of what work was left to do from a test writing perspective so I tried to run the "Code Coverage" report in Visual Studio. During the test runs kicked off by the report, none of my calls to GetBackingField() succeed. They all work as expected in other scenarios though - including using the library and running the tests manually (Live Unit Testing seems to get stuck and never discover the tests which I suspect is related to the coverage report). The error that gets logged during the report generation is:

System.ArgumentException: Value does not fall within the expected range. at Mono.Reflection.BackingFieldResolver.GetBackingField(MethodInfo method, ILPattern pattern) at Mono.Reflection.BackingFieldResolver.GetBackingField(PropertyInfo self)

If you have any ideas, I'd very much appreciate it. I can live without the code coverage report though. At this point I'm more curious about why there is divergence.

My project is a .NET Standard Class Library and my testing project is .NET Core 3.1.

jbevain commented 3 years ago

Hi @justincook-amcom,

It's very likely that Code Coverage is instrumenting the code to report the actual code coverage data, so the pattern of code that this library uses to detect which field is the backing field is not found, and we end up throwing an argument exception.

I think you have 2 options:

1) You could either try to change this library to adjust to the pattern of the getters 2) Live without code coverage :)

justincook-amcom commented 3 years ago

Appreciate your response. I assumed something had to be different at the IL level, but admittedly, I'm out of my depth here.

At this point, I'll probably just live without code coverage. Just wanted to make sure I wasn't missing some configuration setting.

Thanks again!