Castle Windsor 2.1, Dynamic Proxy 2.2 and more released!

Update: Due to a regression error discovered in Windsor Factory Support Facility, we decided to act fast and provide updated package of Windsor, without the issue. Get it here. Sorry for the inconvenience.

Castle Project

What better way of starting a new year can there be, than fresh set of releases from Castle Project?!

Core 1.2 (with more)

Castle Core 1.2 has now its own, separate package. Since the beta few things have changed

  • Email sender component is now integrated with Core, so if you were using it, you now should look for it in Castle.Core.dll. The version shipped with Core 1.2 has the following major breaking changes:
    – Removed Message, MessageAttachment and MessageAttachmentCollection classes and replaced them with MailMessage, Attachment and AttachmentCollection from .NET classes in System.Net.Mail
  • Logging services (integration of Castle’s logging abstraction with log4net and NLog) is now packaged with Core. Notice that these are dependent on Core (just like it used to be). Castle does not have dependency on any of these, so don’t freak out.
  • few minor bugs were fixed, but nothing serious. You should be able to just switch the reference to new version and start using it with no changes to your code.
  • We ship four versions: for .NET 2.0, for .NET 3.5, for Silverlight 3.0 and for Mono 2.6

Get it here.

Dynamic Proxy 2.2

This is a pretty significant release. If you haven’t before, read what we had in beta. Since then, the following has changed

  • Interface members on proxies are behaving almost identical to version 2.1 (change from beta). That means that they take long name of explicit implementation (InterfaceName.Method() instead of Method()), only if you already have a method called Method() on your proxy, either from base class or other interface. And even then, it will still be public, which makes it more transparent to the user.
  • We ship three versions: for .NET 2.0 (this is the last version to support .NET 2.0), .NET 3.5 and Silverlight 3.0

Get it here.

MicroKernel/Windsor 2.1.1 (with support for Silverlight)

Probably the biggest thing about this release is that it includes a Silverlight version. There are a couple more highlights thought

  • revamped typed factory facility
  • added ability to specify Type Forwarding via XML config with the following syntax:
    <component

      id="hasForwards"

      type="Castle.MicroKernel.Tests.ClassComponents.TwoInterfacesImpl, Castle.MicroKernel.Tests"

      service="Castle.MicroKernel.Tests.ClassComponents.ICommon, Castle.MicroKernel.Tests">

      <forwardedTypes>

        <add service="Castle.MicroKernel.Tests.ClassComponents.ICommon2, Castle.MicroKernel.Tests" />

      </forwardedTypes>

    </component>

  • added DynamicParameters (with additional option to return delegate to be called upon component’s destruction)
  • added OnCreate method, which lets you act upon component after it’s created, and before it’s removed (see this Tehlike’s post. Notice it’s not in a facility now, so it just works out of the box.)
  • added lazy component loader
  • major performance improvements in certain scenarios
  • and many bugfixes, see commit log for full list if you’re interested
  • We ship two versions: for .NET 3.5 and for Silverlight 3.0
  • There is also logging facility included in the package. Again – neither MicroKernel, nor Windsor depend on it, so don’t freak out.

Get it here.

We’re already gathering ideas for the next version, so go ahead to the Castle UserVoice page and tell us, what you’d like to see in the next version!

Comments

Congratulations ! now I’ve some work to update my stack 😀

Nice summary. There will also be more project releases to come this month.

Congrats and awesome work. What are the implications of the explicit versus implicit interface implementations? That is, what other features are held back?

@Ryan Cromwell

In beta to allow proxy implement multiple interfaces having methods with identical signatures we defaulted to C#-style explicit implementation of all interface members.

This caused problems with WPF databinding which references properties by name, so we reverted the change back, and by default we leave things like they used to be.

This is something that may look scary in this description but it’s not something that will probably ever affect you – it just works.

You mentioned the fact that WPF using TypeDescriptor for property resolution "looked promising". Is that going to allow the reintroduction of explicit implementation while supporting WPF databinding?

I’m hoping all of the spelunking of the WPF Binding infrastructure I did comes to some good 🙂

@Ryan Cromwell

I backed up from that idea altogether (plugging type description provider to proxies). From WPF databinding’ perspective it should now make no difference, although to be honest I didn’t try it.

Konstantin says:

question about any plans to provide Windsor for Mono 2.6. I have seen that the Castle Windsor project is making test with mono and most of them failed. Do you know something more about this?

@Konstantin,

yes, we accept patches