The Get*Assembly methods in the System.Reflection.Assembly namespace do add a bit of confusion as their description is usually quite brief. In this blog post, I'll add a bit more verbosity by going over some of the possible scenarios... here's the GetEntryAssembly vs GetExecutingAssembly vs GetCallingAssembly.
This method gets the assembly that started the process, pretty much what started the whole chain reaction and the reason why the CPU is looking at the bit of code you've written to make this call.
Suppose you've got a ConsoleApplication1.exe assembly that you double-click on to run, that's the entry assembly - it's as simple as that!
In most large applications, you'll be writing your code as separate modules and would probably have a library of common structures and functions that you would need to access from each of the modules. The GetExecutingAssembly is like a 'Who Am I' for the code to tell which assembly is located in.
Let's say our ConsoleApplication1.exe makes a call to ClassLibrary1.dll. Now, if we were to call GetExecutingAssembly from within a method in ClassLibrary1.dll which in turn is called by a method in ConsoleApplication1.exe, we would get ClassLibrary1 as the executing assembly because that's where the exact code "Assembly.GetExecutingAssembly()" appears.
This gets a *little more* complicated here, but it's still simple enough for you to get with half a brain cell. If you were to look at the stack trace and take one step back from the current method, that's the calling method and wherever it is located is called the calling assembly.
Let's take 2 scenarios here as this takes a little more explaining.
Scenario 1 (GetCallingAssembly): Let's take the case of ConsoleApplication1 calling a method in ClassLibrary1. GetCallingAssembly would give you ConsoleApplication1.
Scenario 2 (GetCallingAssembly): Suppose ConsoleApplication1 calls a method in ClassLibrary1, which calls another method in ClassLibrary1. GetCallingAssembly now gives you ClassLibrary1.