BUG???- Reflection.assembly.GetCallingAssembly returns different values when compiled for Debug or R

[Shawn Hogan]

I'm getting two different results when I call
System.Reflection.Assembly.GetCallingAssembly when compiling in Release and
debug modes. When i compile my application using the "Debug" configuration
my call to GetCallingAssembly returns the assembly name of the project that
contains my form and class(as expected). When i compile using the "Release"
configuration GetCallingAssembly unexpectedly returns System.Windows.Forms.

Below is some sample code that illustrates what i'm trying to do. DO NOT
test this code from the VS IDE. You must compile it and execute it from
explorer. When you run the code in the IDE you will get your application
assembly name as expected.

Create a new windows application and add the following class. Notice that
the function is a shared member:
Public Class Class1

Public Shared Function getCallingAssemblyName() As String

Return
System.Reflection.Assembly.GetCallingAssembly.GetCallingAssembly.FullName

End Function

End Class


Take form1 and place a button on the form with the following code in the
button click.
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

MsgBox(Class1.getCallingAssemblyName)

End Sub

Any Ideas????

Thanks,

Shawn

 

[Mattias Sjögren]

Shawn,

The getCallingAssemblyName method is so short and simple that the JIT
compiler will likely inline the code into the calling method (an
optimization that only happens for release builds), and since the
caller of Button1_Click is the System.Windows.Forms assembly the
result is correct.

You can prevent getCallingAssemblyName from being inlined by adding
the attribute

<MethodImpl(MethodImplOptions.NoInlining)>

to the method. (The MethodImplAttribute is in the
System.Runtime.CompilerServices namespace).



Mattias

 

[Jon Skeet [C# MVP]]

<"Shawn Hogan" <NOSPAM>> wrote:

Any Ideas????

Yup - I'm pretty sure it's due to inlining. In release mode, your
Button1_Click method is effectively calling GetCallingAssembly
directly, at which point it's correct for it to return
System.Windows.Forms.dll.

Do you have any particular reason for using that call rather than
GetExecutingAssembly, however? The latter is more usually useful, I
believe.

One alternative would be to make getCallingAssemblyName with a
MethodImpl attribute which prevented it from being inlined.

 

[Shawn Hogan]

The architecture of the real project is quite a bit more complicated where
the call to GetCallingAssembly is in a different assembly then the main
application. I just posted the simplest case possible for illustration
purposes.

Thanks a lot for the suggestions! Disallowing the method to be inlined works
great!

Shawn

 

[Shawn Hogan]

That works. I see your point about inlining the code and it not being a bug
although an optomization that changes functionality isn't really an
optimization. I have to wonder how many other incidents of optomizations
causing unexpected results exist.

Thanks a lot for the suggestion,
Shawn