Archive for August, 2008
OK, first, apologies for not posting for so long. The initial post was triggered by the Lang.NET symposium. We thought it might be a good idea to come forward with a part of our framework even prematurely, because Lang.NET might trigger enough interest. Seems that this did not happen, and since comments were rare, we decided to continue working on some refactorings, extensions and documentation we wanted to get ready before the real launch. Good news: We’re almost there.
SP1 bug for custom modifiers
The service pack that was released yesterday crashes when certain APIs for custom modifiers are called on generic methods of generic interfaces, like IWhatever<T>.Foo<U>().
Fabian posted a connect bug with details, votes are welcome.
Ayende Rahien has the exact same problem with RhinoMocks. Just like Ayende, a non-redistributable hotfix does not seem like much of a solution to us. Even a redistributable one would make the install experience quite cumbersome. I have no doubt that this would be fixed in the next release, but that’d take some time. A hotfix that gets distributed via Windows/Microsoft Update would be great, of course.
No idea what Microsoft can or will do for us here. However, unlike Ayende, we have no problem with using PSS, the risk of getting charged is not really a problem. But first, let’s give them a few days time to handle this via connect.
Here are our options:
Find another way to get custom modifiers. That would be great, but it’s quite unlikely that another .NET API, if it exists, would not result in the same situation within the CLR.
Use Cecil instead of Reflection. There are a few things we’d like to use Cecil for in the future, but this is not something that we’re going to do tomorrow.
Do nothing and have the users worry about any ExecutionEngineExceptions they might get. (This exception will happily escape any catch block.) No way.
Disable mixins for this scenario (generic methods of generic interfaces)
Not support languages that depend on custom modifiers, like C++/CLI and, according to Ayende, also F# and Spec#
Disable custom modifiers by default, so that users of those languages will have to actively enable it in the configuration, and also take full responsibility for making sure they’re using a .NET release that will not crash.
We’re very likely to go for the last option. We might do that in the Castle project, where Fabian is a commiter (the code that actually triggers this bug is in a DynamicProxy method we’re using), someone else might do it before us, or we could re-implement that DynamicProxy method in our own code, if no agreement can be found among Castle developers.
Opinions are welcome.
SP1 serialization bug
This only broke some unit test, and we were able to work around it. Still, I find it remarkable that a Service Pack would introduce two regression bugs that break our code. Then again, we’re doing some weird stuff, especially in the mixin part, and Fabian really went out of his way to make sure he gets unit test coverage for a wide range of usage scenarios.
(Like, we crashed Mono at Lang.NET with a unit test that tested whether deliberately broken user code would trigger the correct CLR Exception. But I guess it’s part of the magic of an event like that when Marek Safar (the Mono C# guy) analyzes this “bug”, Seo Sanghyeon fixes it within minutes, and Miguel de Icaza triages it for backporting to the Mono release that was branched off the day before. Cool stuff.)
We’ve already discovered quite a few bugs in the past, many of them really low level CLR stuff. (We once even reported a security vulnerability in the CLR, I’ll have to go check what happened to that one. No credits yet.)
But discovering bugs during implementation is one thing. The ratio of bugs that get fixed for the next release is quite OK. Discovering regressions is another story, this breaks code that already worked, or is being used in production, and the ripple effects of such bugs, especially in the CLR itself, can be quite horrible.
All this makes me wonder if Microsoft should not want to include our test suite in their build process. Hell, we’d even give it away without source code so they don’t get blinded by LGPL’ed code!