Bugzilla – Bug 322140
[PATCH] Order of members does not match MS
Last modified: 2007-09-15 21:24:23 UTC
---- Reported by joncham@gmail.com 2006-09-18 13:03:53 MST ---- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: The order of members in a class (specifically methods) does not match that of MS. Specifically, MS matches the order defined in. Mono always seems to put property get/set methods first (with get always before set). Then methods. This is problematic for COM/XPCOM interop. The vtable of unmanaged COM objects is determined by the corresponding layout of the managed interface definition. The MS compilers preserve this information. This means mcs/gmcs cannot be used to compile assemblies that will be used for COM/XPCOM interop, either on mono or on .Net. The sample uses reflection. I know this isn't reliable for method order and it's not what is used for the COM Interop infrastructure, but it's good enough in this case. The other option is to embed mono and look at the unmanaged structures, or use the Marshal.GetComSlotForMethodInfo method which does that. Steps to reproduce the problem: 1. Compile attached sample with gmcs. 2. Compile with csc. 3. Run both under mono to see that order is different. Actual Results: $ mono bug_gmcs.exe get_test1 get_test4 set_test4 get_test5 set_test5 test2 test3 Expected Results: $ mono bug_csc.exe test2 get_test1 test3 set_test4 get_test4 get_test5 set_test5 How often does this happen? Everytime. Additional Information: ---- Additional Comments From joncham@gmail.com 2006-09-18 13:04:14 MST ---- Created an attachment (id=170501) Test case (bug.cs) ---- Additional Comments From miguel@ximian.com 2006-10-02 09:46:33 MST ---- This is by design, it is unlikely that this will change anytime soon, the changes required to the compiler are significant. ---- Additional Comments From joncham@gmail.com 2007-01-12 11:29:34 MST ---- A quick note, the member order only seems to matter for interfaces not classes if that would make the solution any easier (although I'm guessing the compiler uses similar code for each). ---- Additional Comments From billholmes54@gmail.com 2007-03-07 17:58:48 MST ---- Created an attachment (id=170502) proposed patch ---- Additional Comments From billholmes54@gmail.com 2007-03-07 18:01:33 MST ---- Created an attachment (id=170503) ChangeLog ---- Additional Comments From billholmes54@gmail.com 2007-03-07 18:04:28 MST ---- I have been running with the proposed patched since January 17 2007. Although it not a complete fix for all member ordering of a class, it will meet the needs of COM Interop. ---- Additional Comments From miguel@ximian.com 2007-03-19 18:06:40 MST ---- Could we get detailed ChangeLogs for this change? It looks big, so a rationale for the changes would be very useful. ---- Additional Comments From billholmes54@gmail.com 2007-03-20 18:22:35 MST ---- Created an attachment (id=170504) Updated patch with ChangeLog ---- Additional Comments From miguel@ximian.com 2007-03-20 18:25:49 MST ---- Please commit + close ---- Additional Comments From billholmes54@gmail.com 2007-03-21 13:55:59 MST ---- commited to svn - r74749 ---- Additional Comments From gert.driesen@pandora.be 2007-04-18 09:01:54 MST ---- On MS, the order is different if you run the test app on 1.1 or 2.0: MS .NET 2.0: test2 get_test1 test3 set_test4 get_test4 get_test5 set_test5 MS .NET 1.1: set_test5 get_test5 get_test4 set_test4 test3 get_test1 test2 OK Also, compiling an application using csc 1.0 and then forcing it to run on the 2.0 CLR (by setting the supportedRuntime in the application configuration file) yields the same result as an application built using csc 2.0. ---- Additional Comments From joncham@gmail.com 2007-04-18 10:22:57 MST ---- Created an attachment (id=170505) test.zip - Updated test case ---- Additional Comments From joncham@gmail.com 2007-04-18 10:26:25 MST ---- I attached a better test case. Previously I used reflection which I stated was not a reliable way to determine order. I have attached a test which actually uses COM Interop. Note that things seem to be working correctly, i.e. both mono and. Net have the same output. $ ./test.exe Meth1 Meth2 Meth3 PropSet PropGet $ mono test.exe Meth1 Meth2 Meth3 PropSet PropGet Thus, this bug is fixed as far as I am concerned since I opened it in regards to COM Interop. If there is problems with member order dealing with reflection, I would open a new bug or ignore as reflection has no guarantee of member order (and in fact MS changes it between releases). Imported an attachment (id=170501) Imported an attachment (id=170502) Imported an attachment (id=170503) Imported an attachment (id=170504) Imported an attachment (id=170505) Unknown operating system unknown. Setting to default OS "Other".