re-motion Team Blog

From the Team

.NET 3.5 SP1 broke some scenarios for mixins

with 4 comments

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

Here’s another connect bug: Be careful with static members of ISerializable types. (Be sure to read Hรถcke’s comment on the validation page, this seems to be worse than it appeared)

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! ๐Ÿ˜‰

– Stefan

Written by Stefan Wenig

August 14th, 2008 at 9:09 am

Posted in lang.net,mixins

4 Responses to '.NET 3.5 SP1 broke some scenarios for mixins'

Subscribe to comments with RSS

  1. I remember Bill Gates: Only a newer version is a better version ๐Ÿ˜‰

    SP1 Changes “overview”:
    http://codebetter.com/blogs/patricksmacchia/archive/2008/08/13/net-3-5-sp1-changes-overview.aspx

    Just waiting for SP1b, SP1 post SP, KB99999 or whatever …
    Workaround: Do not use this SP …

    Imho a SP should only contain fixes and (if possible) no new features and no breaking changes of course …

    hfrmobile

    20 Aug 08 at 10:11

  2. Hello Stephane,

    I wonder if this was a regression from the 3.5 SP1 betas, or if this was included in the betas, and nobody caught this one on time?

    Miguel

    Miguel de Icaza

    22 Aug 08 at 17:35

  3. Miguel,

    frankly, we don’t know. We were quite busy during the beta period, and noone really cared to check. There’s a lesson in it for us too, but I’d still like to have MS use external test suites like ours. They’d get more immediate feedback, and we’d save us some work too ๐Ÿ˜‰
    Otherwise, we’d have to test both early betas (for bugs that take a long time to fix) and late betas (for bugs that get introduced late). And there’d still be no guarantee that the last round of fixes before RTM won’t break anything.
    I bet the Core CLR team benefitted a lot from the DLR test suite already, so the idea of using other projects’ test suites shouldn’t feel too way out for them. Let’s see how they respond (I’ve followed up via email).

    I imagine you have experienced similar things in Mono. Are you interested in our test suite, or is the Mono project completely relying on the community here? I guess you do execute the DLR tests yourselves?

    – Stefan

    Stefan Wenig

    24 Aug 08 at 10:06

  4. The sp1 totally broke my site. I was using WPF to render combination of images and vector graphics on the fly. After installing SP1 rendering just stopped working. I don’t care about all the changes in SP1 combined, but the fact that it breaks my site is very important. I will keep using .net 3.5 for now, but it could be hard to avoid SP1 as it is required by some new software coming out of MS.

    Michael

    27 Aug 08 at 01:27

Leave a Reply