[Mono-dev] Porting mcs to IKVM.Reflection
kornelpal at gmail.com
Tue May 4 12:43:04 EDT 2010
mcs creates an assembly, then creates types, and only after that is
processing the custom attributes. This is how attributes and even
assembly name (not the name part) can change after definition. Although
there are some other self referencing cases, this order of
creation/definition is required especially when building mscorlib.dll.
At least some cases of these requirements could be eliminated by doing
dependency analysis but there is no use to introduce extra complexity
when the solution is very simple.
All of these functions are implemented as hacks in Mono's
Blob encoded pseudo custom attributes are supported by Mono. I've added
decoding because they weren't ignored, exceptions were thrown instead.
I think that the only problem is that I've removed the exception when
emitting backward jumps but since things were working so far, I haven't
tried to resove that issue yet. (This is a work-in-progress state.)
Unlike Java, C# has support for backward jumps, so does
System.Reflection.Emit so support for that will have to be implemented.
Some notes on IKVM.Reflection:
First of all, thank you very much for creating it, since it's very unique.
Based on your questions I belive that you are trying to remain
compatible with MS.NET. This good, because both IKVM and mcs has a
dynamic mode that is generating code for direct execution that requires
System.Reflection.Emit. And to some extent enables IKVM.Reflection to be
a drop-in replacement for System.Reflection.Emit on runtimes that have
no built-in support.
I on the other hand belive that removing arbitrary limitations of
System.Reflection.Emit (like preventing access to TypeBuilder's
member-builders), and adding missing functionality would make sense.
Mono.Cecil is a great tool but it targets tools operating on metadata
rather and is too abstract and complex for compilers. It also has a
larger memory footprint. So I belive that there is a need for
IKVM.Reflection as a replacement for MS.NET's System.Reflection.Emit as
I also like the concept of having a Universe since that makes possible
to have multiple compiler instances in the same AppDomain.
I belive that pseudo custom attributes and unmanaged resource generation
does not fit well to the concept of System.Reflection.Emit. I would
rather remove support for both of these and introduce __methods for
setting metadata that currently is built from pseudo custom attributes.
Unmanaged resource generation could be automated (and customized) by
using a dedicated class. This would be much faster than encoding (either
binary or just the constructor arguments) and then decoding pseudo
I also belive that CustomAttributeData should not be used as a provider,
__GetCustomAttributes (non-standard since is returning constructor
arguments rather than class instance) methods should be added to
reflection classes. An ICustomAttributeProvider interface (with
IsDefined and __GetCustomAttributes methods) would be very useful as well.
As a conclusion I would be happy to see features (that make sense) in
IKVM.Reflection.Emit that are not present in System.Reflection.Emit.
Jeroen Frijters wrote:
> Thanks for the IKVM.Reflection patches. I have a few questions about some of the changes.
> - Why are the various _SetAttributes methods and the AssemblyBuilder.__SetName() methods necessary?
> - Do you really need blob encoded pseudo custom attributes in the version info? I intentionally don't suppor that (and also include the attributes as regular attributes) to be compatible with .NET
> - Why are all the stack height asserts commented out in ILGenerator, do you think they are wrong?
>> -----Original Message-----
>> From: Kornél Pál [mailto:kornelpal at gmail.com]
>> Sent: Tuesday, May 04, 2010 2:03 PM
>> To: mono-devel
>> Cc: Miguel de Icaza; Marek Safar; Jeroen Frijters
>> Subject: Porting mcs to IKVM.Reflection
>> Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a
>> try to port mcs to IKVM.Reflection.
>> I addition to being able to have a single binary, mcs could run on
>> MS.NET and we would not have to break MS.NET compatibility in
>> I've attached some work in progress patches both for mcs and
>> I was impressed by the result that mcs is able to bootstrap itself,
>> compile mscorlib.dll and its other requirements, and the resulting mcs
>> is able to compile a bunch of Mono assemblies.
>> Missing features:
>> - security attributes
>> - embedded resources
>> - .netmodule support
>> - debug info
>> Also note that I was unable to figure out what MakeExpression methods
>> are supposed to do but I had to disable them because they need
>> System.Reflection types.
>> mcs pathes are licensed under the MIT/X11 license.
>> IKVM.Reflection patches are licensed under the zlib license.
More information about the Mono-devel-list