[Mono-bugs] [Bug 79069][Wis] New - Assembly.GetExecutingAssembly() incorrect behaviour

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by vslugovsky at yandex.ru.

http://bugzilla.ximian.com/show_bug.cgi?id=79069

--- shadow/79069	2006-08-13 12:56:24.000000000 -0400
+++ shadow/79069.tmp.4922	2006-08-13 12:56:24.000000000 -0400
@@ -0,0 +1,45 @@
+Bug#: 79069
+Product: Mono: Class Libraries
+Version: 1.1
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: CORLIB
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: vslugovsky at yandex.ru               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Assembly.GetExecutingAssembly() incorrect behaviour
+
+System.Reflection.Assembly.GetExecutingAssembly() works incorrectly when
+being invoked using reflection.
+
+ Test code:
+               
+Console.WriteLine(System.Reflection.Assembly.GetExecutingAssembl
+y().Location);
+
+MethodInfo mi =
+ 
+(Type.GetType("System.Reflection.Assembly")).GetMethod("GetExecutingAssembly",
+new Type[] {});
+                
+Assembly ass = (Assembly)(mi.Invoke(null, null));
+Console.WriteLine(ass.Location);
+
+////
+
+ With M$ .NET Framework, both output lines are identical.
+ Mono 1.1.15 and 1.1.16.1 shows different assemblies: first is correct
+(current executable), and second is always a path to mscorlib.dll;
+
+ This is due to the implementation of the
+ves_icall_System_Reflection_Assembly_GetExecutingAssembly in
+mono/metadata/icall.c, which refers to the last managed method call. This
+is definetely an inappropriate way to deal with the case of
+reflection-managed calls.