Question

There’s Assembly.GetExecutingAssembly() and Assembly.GetCallingAssembly(). Note that GetCallingAssembly() has a Remark mentioning that depending on how JIT inlining behaves it may be possible that one method is (or is not) inlined into another and so GetCallingAssembly() returns varying results.

Now how is GetExecutingAssembly() different? JIT inlining could technically inline the code that calls GetExecutingAssembly() and so that code now belongs to a different assembly and depending on whether that happened GetExecutingAssembly() can just as well produce varying results.

Why doesn’t GetExecutingAssembly() description have remarks mentioning JIT inining similar to what GetCallingAssembly() description has?

Answer 1

The GetExecutingAssembly method is not susceptible to JIT inlining because of the same reason MethodBase.GetCurrentMethod is also not susceptible since they are implemented in a similar way.

Both methods declare a local variable of a special enumeration StackCrawlMark and initialize it to StackCrawlMark.LookForMyCaller. This local variable has the side effect of preventing the method calling into GetExecutingAssembly or GetCurrentMethod from being inlined which will then guarantee correct results.

This is supported by experimentation and also by the comment associated with this enumeration in the SSCLI20:

// declaring a local var of this enum type and passing it by ref 
// into a function that needs to do a stack crawl will both prevent inlining of 
// the calle and pass an ESP point to stack crawl to
//
// Declaring these in EH clauses is illegal; 
// they must declared in the main method body

The reason GetCallingAssembly is susceptible is because you’re looking for the caller’s caller and the local variable only guarantees that the caller is not inlined, which means that the grandparent method can be inlined leading to an unexpected result.