Reflection only now supported in Mono

I've finally committed the code to support Reflection only methods in Mono to the SVN repository. Basically, the methods are designed to be useful in those cases when only metadata is needed, and no methods/fields/properties are used/invoked. This is specially good with tools that only need to load the metadata information (such method name, parameter types, field types, etc) to show app information, or have special neeeds.

A good description can be found here. This new api will be part of the next release of .Net (Whidbey), and currently no more information is avalaible.

However, here I have some additional details:

• Reflection only and non reflection only assemblies are loaded separately, which means that it is possible to have loaded in both ways the same assembly.


• MemberInfo and other elements will throw InvalidOperationException when calling Invoke(), which is the exception used to warn that the members are in a reflection only assembly, and thus can not be invoked/assigned.


• References are not automatically loaded, which means that all of them should be manually loaded. Mscorlib is the only one that is not needed in this form, and currently we use the loaded one as if it were a reflecion only. Note that we *could* change this in the future, altought I don't think it will happen.


• Custom Attributes are retrieved in the form of CustomAttributeData class, which contains the attribute information in a 'raw' way. CustomAttributeTypedArgument and CustomAttributeNamedArgument structs will contain the information about typed and named argument, respectively. (Note: We currently don't support this; however, I hope to have them in SVN as quick as I can)

Something very important to be noted, is the fact that we currently don't avoid the creation of some inneccesary data structures for ReflectionOnly assemblies. That will likely change in the next days/weeks/months, and it's a matter of performance, not of behavior (the impact is not that big).

Thanks to Zoltan and Paolo for their help.

I'm in Monologue!!!

Yeah, the next post will be the first one in being included in Monologue (sindicalization around Mono project).

Monologue can be found here.

Great essay about the current the most known political problem in Mexico

Found a great article about the political situation against Manuel Lopez Obrador, where together the two most important political groups, with the current federal government, try to keep him out of the electionf for president next 2006. The link, at Proceso, here.

Problems with the C Mono api

I spent almost a day solving a small problem I had creating structs from the C Mono api. When I returned this instance of struct, an exception was thrown, advising that it was not having a value...

Struct types in Mono are value based types, and since that, they cannot be null. Based in this, I could not figure out the reason for the exception. Then I remembered a similar problem I had when I defined a function, returning a MonoObject * (MonoObject* is the representation of the object C# type), that did not return the correct value (I forgot to add the return statement).

To create an instance in the C api, the class must be passed (a look into mono/samples/embed is a good beginning to begin to understand the C api), which is a MonoClass*. So, with classes you do:

MonoObject *obj;
...
/* mono_object_new (MonoDomain *d, MonoClass *klass)
 * receives as first arg the current domain and a pointer to
 * a defined class */
obj = mono_object_new (mono_domain_get (), klass);

/* Constructors must be called (they are common MonoMethod*'s) after the object is
 * created; basically, with mono_object_new the object is only allocated.
 * Note: mono_runtime_invoke (MonoMethod*, MonoObject*, 
 *       void **params, MonoObject **exception)
*/
mono_runtime_invoke (ctor, obj, params, NULL);

/* Return a fresh instance, with its constructor called */
return obj;

But..., there is the trick for structs (I had to go and read the code of Reflection after a day suffering. Mental note: remember to go to check the code when having a weird error). The trick here, is to unbox the struct before calling the constructor. Structs are allocated as value types, and finishing the stack frame where they were defined (the function itself), they dissapear. Boxing refers to the process of allocating a structure (and anything value based) as a reference type. Unbox is the oposite.

So, we would have this code for structs:

/* First, create the instance, boxed */
obj = mono_object_new (mono_domain_get (), klass);

/* Unbox on a void* variable */
o = mono_object_unbox (obj);

/* Call the method/constructor on the unboxed */
mono_runtime_invoke (ctor, o, params, NULL);

/* But ... return the MonoObject* representation */
return obj;

The question here is: structs created from the C Mono api must be created using mono_object_new, which creates boxed structs? The answer is: yes. The runtime can know the times of structs, but, the hacker would not be able to know this, even at compile time.

I hope this helps anybody (in the future, mostly) to avoid this problem.

Latest news

Haven't post recently, mainly because I've been doing some work that is not very fun to be shown here.

Anyway, we are releasing Mono 1.1.4, which is the development version, and we will mark it as stabler than the 1.X series, because of minor number of bugs, better performance, and more features.

Yesterday had chance to met Miguel de Icaza at a conference that took pace at the UNAM, in Mexico city, and finally received my so long-time-wished Mono t-shirt ;-)

Finally, I want to share my my very friends a very delicious and bright idea of my friend Mauricio, who, in a moment of ilumination -both alcoholic and sex ..ehr, I mean, intelectual- reached the maximum state of inteligence, and changed the way I see the world now:

We are ugly man, we are ugly

(We was explaining me the big importance of having charisma with ladies, and how, being that much awful and super mega ultra ugly, just like he himself is, can someone be a 'ladiesman', and refering to both of us when he said that of 'we are ...').

Thanks Maurimal. You have changed the world ;-)