[Mono-dev] Porting mcs to IKVM.Reflection

Marek Safar marek.safar at gmail.com
Thu May 6 10:00:05 EDT 2010

> I'm trying to keep differences minimal, and I have no intention to 
> drop System.Reflection support:
> using IKVM.Reflection;
> using IKVM.Reflection.Emit;
> using Type = IKVM.Reflection.Type;
> #else
> using System.Reflection;
> using System.Reflection.Emit;
> #endif
I'd prefer not to go this route but it will require some gmcs 
refactoring to avoid it.
> My other modifications are around hacks for overcoming limitations of 
> System.Reflection[.Emit] that make mcs depend on the Mono runtime, so 
> actually I'm just trying to make the code hack free.
> My understanding is that basically we only have two compilers:
> - static:  mcs.exe, gmcs.exe, smcs.exe, dmcs.exe (for each profile)
> - dynamic: Mono.CSharp.dll, that is used by Microsoft.CSharp.dll and
>            csharp.exe
That's not entirely accurate. We have REPL mode which is another dynamic 
version of all *mcs.exe running on top of SRE and there is possibility 
in near future for MD to plug-in with it's own type system mostly based 
on Cecil and most likely another type system is coming with .NET v-next 
which should expose C# DOM via .NET interfaces.
> As I see (based on your explanation) only the dynamic (as in the above 
> list) compiler is using MakeExpression methods that will have to use 
> System.Reflection anyway because they generate code that can be 
> executed without saving an assembly first that requires runtime 
> support. Because of conditional compilation and minimal code changes, 
> having support for both SRE implementations - in my opinion - is not 
> (significantly) increasing code maintenance requirements.
> If the above assumptations are correct then all the MakeExpression 
> methods can safely be #if-ed out when building the static compilers 
> and thus there are no features that cannot be implemented by using 
> IKVM.Reflection. Is this correct?
IKVM SRE like interface is quite disadvantage here. Presumably you could 
reference IKVM with extern alias to avoid System.Type conflicts 
otherwise we would have to alias every IKVM namespace.


More information about the Mono-devel-list mailing list