re:motion Team Blog

.NET 3.5 SP1 service release coming!

re:motion Team — Wed, 24 Sep 2008 08:50:30 GMT

It seems that sometimes whining helps. After complaining long enough about how the bugs in SP1 affect us and our customers, Microsoft decided to fix the two bugs that bother us. Better yet, those hotfixes (and some others I would guess) will be rolled up in a servicing release for SP1, which will be distributed via Windows Update as soon as SP1 itself gets fixed.

The following has been posted by MS for both bugs yesterday:

We're also in the process of testing a hotfix for this issue. I expect it will be available within a week or so. I'll keep you posted on the status and give you the KB (knowledge base) article number and how you, and other customers, can acquire the hotfix once it's available.
Additionally we intend to include this fix in an upcoming servicing release, a roll-up of sorts, which will be released in synch with 3.5SP1 via Windows Update. I.e. when 3.5SP1 starts getting pushed out broadly, so will this fix. We’re still working out the exact timeframe for this release but our hope is before the end of the year.

Thanks to Ayende Rahien, who helped me make that case with some numbers off affected projects and users, and Charlie Calvert of Microsoft who carried our feedback to their management, who eventually decided to do the right thing. It's good to know that when stuff like that happens, these guys are willing to do what it takes so this won't hit us too hard.

For other people who have to deal with SP1 regression problems in similar situations, I would think that now might be a good time to try and get them to include your favorite bug in this roll-up. Providing some background about your particular situation seems to help.

Update: Just found out that Scott Hanselman already blogged about this with much more detail.

.NET 3.5 SP1 broke some scenarios for mixins

re:motion Team — Thu, 14 Aug 2008 09:09:17 GMT

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

Announcing re:motion mixins at lang.net 2008

re:motion Team — Mon, 28 Jan 2008 08:16:46 GMT

Hi there, I'm Stefan Wenig, from rubicon informationstechnologie in Vienna, Austria. My coworker Fabian Schmied and I just arrived in Redmond for lang.net 2008. We'll be introducing a new mixin mechanism for C# on Tuesday, and we're going to provide some coverage of mixins here. If time allows, we might also blog a bit about other interesting stuff from lang.net, of which there should be plenty.

re:motion is a framework for .NET enterprise applications that we've been developing at rubicon for some years now. The mixin mechanism is just one of the libraries it contains, and we're in the process of moving it all to a OSS development model. If that sounds interesting to you (it should, I promise!), you'll soon find more information on this blog and on the home page.

This has to be enough for now. Our attendence at lang.net has been on pretty short notice, we left Vienna 22 hrs ago. I'm going to sleep, and tomorrow we'll have to, guess what, finish our presentation.

The next week will see more blogging about re:motion.

- Stefan

Lang.NET talk video available

Blog Author — Wed, 20 Feb 2008 13:14:22 GMT

Hi there as well! I'm Fabian Schmied, also from rubicon.

Today, Microsoft has published the video of the talk Stefan and I gave at the Lang.NET symposium 2008, you can find it here. In the talk, Stefan explains our original motivation for creating re:motion mixins, our mixin library. I give a technical overview about the library (including a very short demo).

This is just the first post providing some insight about re:motion (especially re:motion mixins), though only indirectly. We'll give more details, explanations, and samples in the near future. In the meantime, feel free to ask specific questions by posting comments to this blog.

- Fabian

Introducing mixins (finally)

re:motion Team — Wed, 20 Feb 2008 02:54:40 GMT

Sorry for the delay. After lang.net I spent some time having fun with a bronchitis I caught there (I blame winter-season air conditioning). You can hear it in the talk too, but anyway, here we go.

In the last few months, we have developed a mixin mechanism for static .NET languages, which we're using with C#. After a few months of internal dogfooding, we're now ready to release it under an OSS license.

We believe that it provides several useful mechanisms for C# 2.0 and above today. Our mechanism is both powerful and easy to use, syntactically and semantically. We're using it internally both for typical development problems that would traditionally require duplicate code in C#, as well as for componentized product line development.

Here's a simple example:

[Uses (typeof (MyMixin))]
public class Target
{
}

public class MyMixin: IMyMixin
{
}

Target t = ObjectFactory.NewObject<Target>().With(); // With provides the constructor arguments 
IMyMixin m = (IMyMixin) t;

All instances of the target type now implement the IMyMixin interface (as long as they are created via ObjectFactory).

The trick here is that mixins are in reality a composition mechanism, but implementing mixins feels more like inheritance. You define a mixin much like a subclass, and when you use the factory, a subclass is created that does all the composition for you. That gives you most of the power of multiple inheritance (and then some) without its specific problems, like diamond inheritance.

If the target type implements an interface, you can skip the casting by deriving what we call a "complete interface". (Remember that whatever you might have heard about multiple inheritance, it's generally assumed to be safe for interfaces.)

public interface ICompleteTarget: ITarget, IMixin {}
ICompleteTarget t = ObjectFactory.NewObject<ICompleteTarget>().With();

This is a general property of re:motion mixins: Everything works a bit smoother if you're using interfaces a lot, but you can always work around it if that is not the case.

Here's an advanced (if somewhat contrived) example:

public class Target: ITarget
{
  public Target (string name) {...}
  public virtual string GetSomething() {...} 
} 

public interface IMixin
{
  void ResetCache();
}

[Extends (typeof (Target))]
public class Mixin: Mixin<Target>, IMixin 
{
  private string _cache = null;

  [OverrideTarget] public string GetSomething ()
  {
    if (_cache == null)
      _cache = Base.GetSomething();
    return _cache;
  }  

  void ResetCache()
  {
    _cache = null;
  }
}

[CompleteInterface (typeof (Target))]
public interface ICompleteTarget : ITarget, IMixin {} 

ICompleteTarget t = ObjectFactory.NewObject<ICompleteTarget>().With("stringArg");

This simply creates a mixin that caches the result of GetSomething(). This also points out the difference between mixins and generic AOP mechanisms: An AOP system would allow you to create code that caches every method/property (or lets you choose them based on attributes or regular expressions). Mixins are strictly non-generic. They work on known interfaces and methods, which means that we don't get the complexity overkill of AOP (but also not the full power of AOP).

(That said, there are ways to use the mixin infrastructure for more generic behavior, but that's a different story.)

Here's a short list of features:

Create full-featured mixins (implement new interfaces, override virtual methods/properties/events, call "base"-methods, keep state) using the most simple syntax we could possibly come up with.
Include one or more mixins from a target type (similar to multiple inheritance) and even override methods of the mixin OR
define a mixin for one or more existing types, and just have it magically applied to that type (as long as instances are created via a factory method). You can even create a mixin in a new assembly, copy it into an app's bin directory and have it picked up automatically, so that existing types just magically "change" (we're using this for product extensibility and product line development)
This even works if you apply multiple mixins to a single target type. If several mixins override the same method, they are automatically ordered based on their dependencies.
Automatically implement "complete interfaces", i.e. interfaces that include members of both target type and mixins, so you don't have to cast that much.
For those of us who use WebForms, which "new" up objects all the time without any chance to use a factory method, there is a special mechanism that replaces the static types in the markup with generated types at runtime.
You can apply mixins to any public, non-sealed type, and you may use any type as a mixin. For advanced features like overriding however, the type that does the overriding of course has to be mixin-aware. Also, mixins are easier to use if both target types and mixin types expose their features via interfaces, but this is not a requirement.
You can modify the static assignment of mixins to types at runtime.
Types with mixins are fully serializable (assuming that all underlying types are).
There's a load of advanced features, like copying mixin attributes to target types, reflecting on mixin types, customizing ordering via dependencies, manually instantiating mixins (behind the scenes, it's just composition after all), scoped configurations, imperative configuration, parallel class hierarchies between target and mixin types, and type deduction for generic mixin types, to name just a few. For those who really know what they are doing ;-)

This sounds more complicated than it is, in most cases you just write a mixin class, optionally apply a few attributes for overriding, and then specify which mixins you want to use for which target type. We've used this library internally now for a few months, and feedback has been very good so far. It turned out that, while started primarily with a focus on product line development, mixins are a very useful general-purpose design tool.

Finally, a word about the preview version you can download from here: It is not yet open source, basically because we didn't get around to finish all the work we need to do first (license headers etc). Since mixins are only a part of what re:motion is providing, this is quite a bit of work. The other thing is that we're using Castle's DynamicProxy library. That's because Reflection.Emit is a pain to work with directly (mostly because of the less-than-helpful error handling). So we're using DynamicProxy's type emitters, but we're not using its proxy mechanisms. So don't jump to any conclusions about our implementation just from the fact that we're referencing it.

OK, that's it for today, download and have fun!

- Stefan