Castle Windsor 2.1, Dynamic Proxy 2.2 and more released!

Update: Due to a regres­sion error dis­cov­ered in Wind­sor Fac­tory Sup­port Facil­ity, we decided to act fast and pro­vide updated pack­age of Wind­sor, with­out the issue. Get it here. Sorry for the inconvenience.

Castle Project

What bet­ter way of start­ing a new year can there be, than fresh set of releases from Cas­tle Project?!

Core 1.2 (with more)

Cas­tle Core 1.2 has now its own, sep­a­rate pack­age. Since the beta few things have changed

  • Email sender com­po­nent is now inte­grated with Core, so if you were using it, you now should look for it in Castle.Core.dll. The ver­sion shipped with Core 1.2 has the fol­low­ing major break­ing changes:
    — Removed Mes­sage, Mes­sageAt­tach­ment and Mes­sageAt­tach­ment­Col­lec­tion classes and replaced them with MailMes­sage, Attach­ment and Attach­ment­Col­lec­tion from .NET classes in System.Net.Mail
  • Log­ging ser­vices (inte­gra­tion of Castle’s log­ging abstrac­tion with log4net and NLog) is now pack­aged with Core. Notice that these are depen­dent on Core (just like it used to be). Cas­tle does not have depen­dency on any of these, so don’t freak out.
  • few minor bugs were fixed, but noth­ing seri­ous. You should be able to just switch the ref­er­ence to new ver­sion and start using it with no changes to your code.
  • We ship four ver­sions: for .NET 2.0, for .NET 3.5, for Sil­verlight 3.0 and for Mono 2.6

Get it here.

Dynamic Proxy 2.2

This is a pretty sig­nif­i­cant release. If you haven’t before, read what we had in beta. Since then, the fol­low­ing has changed

  • Inter­face mem­bers on prox­ies are behav­ing almost iden­ti­cal to ver­sion 2.1 (change from beta). That means that they take long name of explicit imple­men­ta­tion (InterfaceName.Method() instead of Method()), only if you already have a method called Method() on your proxy, either from base class or other inter­face. And even then, it will still be pub­lic, which makes it more trans­par­ent to the user.
  • We ship three ver­sions: for .NET 2.0 (this is the last ver­sion to sup­port .NET 2.0), .NET 3.5 and Sil­verlight 3.0

Get it here.

MicroKernel/Windsor 2.1.1 (with sup­port for Silverlight)

Prob­a­bly the biggest thing about this release is that it includes a Sil­verlight ver­sion. There are a cou­ple more high­lights thought

  • revamped typed fac­tory facil­ity
  • added abil­ity to spec­ify Type For­ward­ing via XML con­fig with the fol­low­ing 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 Dynam­ic­Pa­ra­me­ters (with addi­tional option to return del­e­gate to be called upon component’s destruction)
  • added OnCre­ate method, which lets you act upon com­po­nent after it’s cre­ated, and before it’s removed (see this Tehlike’s post. Notice it’s not in a facil­ity now, so it just works out of the box.)
  • added lazy com­po­nent loader
  • major per­for­mance improve­ments in cer­tain sce­nar­ios
  • and many bug­fixes, see com­mit log for full list if you’re interested
  • We ship two ver­sions: for .NET 3.5 and for Sil­verlight 3.0
  • There is also log­ging facil­ity included in the pack­age. Again – nei­ther Micro­Ker­nel, nor Wind­sor depend on it, so don’t freak out.

Get it here.

We're already gath­er­ing ideas for the next ver­sion, so go ahead to the Cas­tle User­Voice page and tell us, what you'd like to see in the next version!

  • http://jfromaniello.blogspot.com/ José Romaniello

    Con­grat­u­la­tions ! now I've some work to update my stack :D

  • http://jonorossi.com/blog/ Jonathon Rossi

    Nice sum­mary. There will also be more project releases to come this month.

  • http://blogs.cromwellhaus.com/ Ryan Cromwell

    Con­grats and awe­some work. What are the impli­ca­tions of the explicit ver­sus implicit inter­face imple­men­ta­tions? That is, what other fea­tures are held back?

  • http://kozmic.pl/Default.aspx Krzysztof Koźmic

    @Ryan Cromwell

    In beta to allow proxy imple­ment mul­ti­ple inter­faces hav­ing meth­ods with iden­ti­cal sig­na­tures we defaulted to C#-style explicit imple­men­ta­tion of all inter­face members.

    This caused prob­lems with WPF data­bind­ing which ref­er­ences prop­er­ties by name, so we reverted the change back, and by default we leave things like they used to be.

    This is some­thing that may look scary in this descrip­tion but it's not some­thing that will prob­a­bly ever affect you — it just works.

  • http://blogs.cromwellhaus.com/ Ryan Cromwell

    You men­tioned the fact that WPF using Type­Descrip­tor for prop­erty res­o­lu­tion "looked promis­ing". Is that going to allow the rein­tro­duc­tion of explicit imple­men­ta­tion while sup­port­ing WPF databinding?

    I'm hop­ing all of the spelunk­ing of the WPF Bind­ing infra­struc­ture I did comes to some good :)

  • http://kozmic.pl/Default.aspx Krzysztof Koźmic

    @Ryan Cromwell

    I backed up from that idea alto­gether (plug­ging type descrip­tion provider to prox­ies). From WPF data­bind­ing' per­spec­tive it should now make no dif­fer­ence, although to be hon­est I didn't try it.

  • Kon­stan­tin

    ques­tion about any plans to pro­vide Wind­sor for Mono 2.6. I have seen that the Cas­tle Wind­sor project is mak­ing test with mono and most of them failed. Do you know some­thing more about this?

  • http://kozmic.pl/Default.aspx Krzysztof Koźmic

    @Konstantin,

    yes, we accept patches