Monday, December 10, 2007

My Love-Hate Relationship with Mono.Cecil

I managed to fix the bug from my previous rant about Mono.Cecil, and I've even managed to implement some jaw-dropping method interception capabilities using that library. I can now intercept any method from nearly any .NET assembly, regardless of whether or not that method is static, sealed, and even non-virtual. The only problem with this library is that the more I explore its capabilities, the more I find myself becoming too dependent on Mono.Cecil. It might take me another year of research just to get LinFu.Reflection.Emit up and running, so for now, I really don't have any other viable alternatives to use (other than Mono.Cecil, of course).

It's ultimately a 'marriage of convenience' of sorts, and until I can make an alternative of my own, a figurative divorce is not an option.

One of these days, my bouts of NIH (Not Invented Here) syndrome are either going to either going to make me rich, or just plain insane, and since the first option doesn't seem so possible, I think the 'insanity' option just might get the best of me.


  1. And other than ranting, did you cared to submit a single bug-report to Mono .Cecil ?

    We, and by we I mean I, are pretty fast to fix bugs you know

  2. I figured out the cause of the bug.

    The bug turned out to be in line 981 of ReflectionWriter.cs. The ReflectionWriter throws a NullReferenceException when the writer tries to write a type that is null.

    That bug is caused when you try to write an assembly and you are referencing a Variable in your IL that isn't a part of the MethodBody.Variables collection. It was a mistake on my part, but it took me quite a while to figure out.

    It would have been ten times easier to find if Cecil did some verification on the method body before emitting the actual bytecodes itself.

    Aside from that, the library itself is still quite useful, so as I mentioned before, I'll still be using it in the foreseeable future.

  3. It doesn't quite care if you've find the source of the bug. My point is that you are ranting without having doing anything to improve the situation.

    You could have mailed the mono-cecil group, you could have filed a bug in Mono's bugzilla, you could have even mailed me directly, it would have been a step towards fixing the bug.

    You want Cecil to perform checks before emitting, good, file a bug «Cecil doesn't do any check before emitting the CIL, it can leads to some crashes, here's a repro».

    That, would have been useful.

  4. Of course it doesn't care if I found the source of a bug, since bugs can't really fix themselves, right? :)

    I'm not telling the program what the bug is--I'm now telling you (since you're the principal author) what/where the bug is so that you can do something about it.

    I have every right to be frustrated with Cecil regardless of whether or not I submit a formal bug report to the group or not. I understand your point that it probably would have been more useful to report the bug instead of rant about it, but at this point, it's still rather moot since:

    1) I found out the source of the bug and made sure that it won't happen in my code again
    2) It no longer causes me problems
    3) It still left me very frustrated, leading to my ranting about Cecil's inefficiency.

    There seems to be an unstated premise here that says that I must somehow "earn" my right to be frustrated with your work before I can critique it, and that's completely false. The fact that you made Cecil an Open Source project gives anyone (including myself) with access to its source code the right to look at your work, and comment about it.

    Now, whether you agree with my comments or not is really irrelevant at this point. Everyone has a right to comment on your work with Cecil, just as they have the right to comment on my work with LinFu if there's something right or wrong with it.

    More importantly, since I've seen the source code to Cecil, my criticism still stands.

    So the moral of the story is this:

    Taking the extra five minutes to make sure that your method parameters aren't null references will save others the pain of having to spend five hours trying to figure out where your library went wrong. Telling them that they should have submitted a bug report doesn't detract from the fact that you omitted some basic error checking in your code in the first place.

    (Anyway, this post is getting WAY too long, so I'm just going to blog about it, instead.)

  5. That was pretty funny.

    You know, I don't pretend to be the best developer around, nor that Cecil is the best piece of code never written, nor that Cecil is the best piece of code that I have actually ever written.

    Most of the Cecil code is 3 years old, and large pieces of it suck beyond the wildest imagination.

    But it's not the point of my comments.

    My point is that you're not doing anything useful to fix the situation (Cecil being buggy on this particular case. Wether you've workaround or not, Cecil still has a bug if it doesn't check arguments).

    And because you're lessoning people about what you thing of development, I would have assumed that you were realizing that the best way to track a bug is not on a rant post, but rather in the tracking system of the project, so it can be actually tracked, categorized, prioritized, and so on.

    What you don't seem to realize, is that I'm actually open to every single piece of comment or criticism about Cecil, as long as the comment is *usable*.

    And going to a rant post is not categorized as usable to me. And it's not going to un-frustrate you. You would have filed a bug, it would have been already fixed, checked in with corresponding unit tests, and we would have been able to move along to the next bug you're facing.

    Sadly, you quite didn't take the road to the usefulness communication in a first place. While plenty of other people are, either on bugzilla or on the mono-cecil google group.

    And, to finish, because everyone have the right to see the sources of Cecil, and to comment about them, everyone have the right to change them, and submit patches as well. Here again, plenty of people are doing so. You didn't. Too bad, both for you and for the rest of the cecil community.

  6. The purpose of my blog isn't to report bugs in Cecil. Its purpose is to record my thoughts, opinions, ravings, and rantings about whatever I decide to choose during the course of my development, regardless of whether you deem it
    than in my *own* blog.

    More importantly, if this rant post is 'useless' to you, then why bother adding a comment in the first place? Calling a 'useless' rant 'useless' just makes your actions seem redundant.

    If, on the other hand, you keep harping about how I should have posted a bug report in your bug tracker, and if that's all you want, then you'll get your bug report.

    Now, was there anything else that you wanted, and am I permitted to say anything I want on my own blog?



Ratings by outbrain