C#: Cannot use in parameter with generic method override on Linux

[impulsh]

An exception is thrown when overriding a generic class method with an in parameter. This works fine on a Windows client and server, but the same code on a Linux server fails loading the assembly. Tested with build 5777.

I'm not sure what version of Mono is used - or how easy it would be to cherry-pick some commits if need be, but I've come across mono/mono#10834 and believe this is the same issue, with mono/mono#12802 being the fix.

Minimal repro:

using CitizenFX.Core;

namespace Test
{
	public abstract class MyGenericClass<T>
	{
		public abstract void MyMethod(in T value);
	}

	public class MyDerivedClass<T> : MyGenericClass<T>
	{
		public override void MyMethod(in T value)
		{
			Debug.WriteLine(value.ToString());
		}
	}

	public class TestScript : BaseScript
	{
		public TestScript()
		{
			MyDerivedClass<Vector3> test = new MyDerivedClass<Vector3>();
			test.MyMethod(Vector3.Zero);
		}
	}
}

Exception thrown:

Failed to instantiate instance of script Test.TestScript: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
  ---> System.TypeLoadException: Could not find method '.ctor' due to a type load error: Type Test.MyDerivedClass`1[T] has invalid vtable method slot 4 with method none assembly:data-0x7fb6516fdda0 type:MyDerivedClass`1 member:(null)
  at (wrapper managed-to-native) System.Reflection.MonoCMethod.InternalInvoke(System.Reflection.MonoCMethod,object,object[],System.Exception&)
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <9391d7651e69459eae268d8a1dfa670f>:0
   --- End of inner exception stack trace ---
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00017] in <9391d7651e69459eae268d8a1dfa670f>:0
  at System.RuntimeType.CreateInstanceMono (System.Boolean nonPublic, System.Boolean wrapExceptions) [0x000a8] in <9391d7651e69459eae268d8a1dfa670f>:0
  at System.RuntimeType.CreateInstanceSlow (System.Boolean publicOnly, System.Boolean wrapExceptions, System.Boolean skipCheckThis, System.Boolean fillCache, System.Threading.StackCrawlMark& stackMark) [0x00009] in <9391d7651e69459eae268d8a1dfa670f>:0
  at System.RuntimeType.CreateInstanceDefaultCtor (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Boolean wrapExceptions, System.Threading.StackCrawlMark& stackMark) [0x00027] in <9391d7651e69459eae268d8a1dfa670f>:0
  at System.Activator.CreateInstance (System.Type type, System.Boolean nonPublic, System.Boolean wrapExceptions) [0x00020] in <9391d7651e69459eae268d8a1dfa670f>:0
  at System.Activator.CreateInstance (System.Type type, System.Boolean nonPublic) [0x00000] in <9391d7651e69459eae268d8a1dfa670f>:0
  at System.Activator.CreateInstance (System.Type type) [0x00000] in <9391d7651e69459eae268d8a1dfa670f>:0
  at CitizenFX.Core.InternalManager.CreateAssemblyInternal (System.String assemblyFile, System.Byte[] assemblyData, System.Byte[] symbolData) [0x0007b] in /src/code/client/clrcore/InternalManager.cs:156

[blattersturm]

Mono version used on both server builds should be equivalent, but see the caveats below as Windows was built from main and Linux was built from patched tags, which diverged at the time.

No such commit has been cherry-picked in anywhere, but it may be Linux is on 5.16 and Windows is on 5.18 as 5.18 and higher on Linux had a weird memory corruption bug (around d1ec7d4 timeframe?), or they may be on different sub-releases.

I'm unable to check this right now or any time soon as the Linux package build trees are on some disconnected SSD or disk image of an old SSD or whatever and I'm not going to dig through this for a minor inconsequential issue that's easy to work around, but FWIW the Windows build seemed to be on mono/mono@ed0d055, or this was an attempt at updating it that never went anywhere and therefore the current tree is lost to time as of a tweak around 76a2919 and apparently that means the Windows bundle did get updated and wasn't reverted when 62e1a14 got reverted in 784088f... or it's which is the same version since e649e9c as that matches the Mono commit's timeframe and Mono's branch model was a bit weird so even though that commit first showed in '6.4' tags, the 5.x branches were seeing a different baseline.

Either way, I'm not sure where the Linux trees went anyway and newer tags had weird memory corruption issues so this can't be acted upon at this time.

Since people also seem to be bumping this issue to be 'looked at' in roundabout ways, which is the only reason I looked into this at all, and I can't deal with that right now (or the emoji responses, really? if you have something to add, use words, or don't add anything), I'll lock this issue.