Rockford Lhotka
    CTO at Magenic
    Author, speaker, software architect
    Creator of the CSLA .NET framework

Home
Blog
CSLA .NET
Magenic
Speaking
Publications
About me
Contact me

Login

Inlining issue with PropertyHasChanged, CanReadProperty, CanWriteProperty

 

The PropertyHasChanged(), CanReadProperty() and CanWriteProperty() methods in CSLA .NET have overloads that allow the developer to call the methods without using a string literal to indicate the property name to which they apply. To accomplish this, the methods use System.Diagnostics to access the stack trace. To avoid the stack from being tampered with by the compiler, these methods are marked with a compiler directive to prevent them from being inlined.

 

    <System.Runtime.CompilerServices.MethodImpl( _

      System.Runtime.CompilerServices.MethodImplOptions.NoInlining)> _

 

    [System.Runtime.CompilerServices.MethodImpl(

      System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]

 

That is good.

 

Unfortunately, your business properties can get also be inlined by the compiler, breaking PropertyHasChanged(), CanReadProperty() and CanWriteProperty().

 

You won’t run into this problem until you build your solution in release mode. In debug mode the inlining won’t occur.

 

To resolve the issue you have two choices:

 

  1. Use the string literal forms of the methods. For instance, PropertyHasChanged("MyProperty")
  2. apply the MethodImplOptions.NoInlining attribute to your business properties

 

Of the two, I would tend to prefer #2 because you preserve the maintainability if your code by avoiding the string literal. However, if you are using code generation to create the bulk of your code, you may opt for #1 because string literals aren’t so bad when created by code gen tools.

 

(Updated 5/5/2006)