Since we already have a abstract class that implements INPC I simply used the PropertyMap.GetProperty(this, ref target) method to get the property name and avoid having to hardcode the name as a string in each Property.
I ran into a slight problem because we have some classes that expose the same field in multiple properties (not necessarily the right thing to do but that's what we've got) and ActiveSharp can't deal with this situation.
My proposed solution was to change ActiveSharp to walk the Stack when it encountered these duplicates. John was kind enough to explain the potential pitfalls and the alternative technique of using marking all Properties with this attribute:
[System.Runtime.CompilerServices.MethodImpl(
System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]The primary issue is around "inlining" methods when the Release code is built. This can result in fewer entries being available on the stack. Therefore a modified GetProperty might work during development but not live.
I read that there are some situations that prevent inlining:
- Methods that are greater than 32 bytes of IL will not be inlined.
- Virtual functions are not inlined.
- Methods that have complex flow control will not be in-lined. Complex flow control is any flow control other than if/then/else; in this case, switch or while.
- Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.
- If any of the method's formal arguments are structs, the method will not be inlined.
For now this appears to be working OK but I might need to revisit when we move to 64bit Windows Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks
Important Note:Running the Release version from within the IDE does not give the same results as running the application as a standalone .exe
No comments:
Post a Comment