Update FTBitmapExtensions.cs#136
Conversation
Added a few more steps to make sure we get the FieldInfo needed for the Mono hack.
|
It would be nice to reference the actual change in mono? I don't doubt the mono folks rename non-public internal structures from time to time, but it would be nice to know why they do it, and what else might be changed together, and possibly relevant. |
|
This seems to be the corresponding change, mono/mono@e33294b#diff-e5aeb604932f29179c83c42a4337e71a48d9b62c36c2a65c68bd6f2f86ed5bd2 , and seems quite extensive. Affect mono 5.8 onwards. It might be interesting to know if the work around is still needed, or a different work around needed. The corefx change is large. |
|
Yes, the work around is still needed.
(ignore the point size discrepancies) I was running on fumes last night after tracking down what the problem was. The whole work around is hacky, even if by necessity. It's always going to be vulnerable to this kind of breakage and I'm not in love with my solution but it will work in this moment. One thing that should be added is a check to see if monoPaletteFlagsField is still null after the for loop and then throw an exception with details to what is going on here for future debuggers. |
|
Yes, I think it should fail on unexpected API change like this, instead of doing garbage. |
|
Previous discussion #55 Upstream mono had moved to github - we probably should (re-)file upstream . |
|
I have re-filed upstream as mono/libgdiplus#702 |
2 participants
Added a few more steps to make sure we get the FieldInfo needed for the Mono hack.