Blogs

» Home » Community » Blogs

Castle Windsor 3.0 is released
Getting closer… Castle Windsor 3 RC 1
Windsor 3 beta 1 – dozen of Nuget packages and SymbolSource.org support
PropertyBagTextWriter (Stream into Dictionary)
Windsor 3 is here
Older entries

Castle Windsor 3.0 is released

Posted 12/16/2011 4:24:30 AM at kozmic.pl

Castle Windsor

After successful beta and RC releases final version of Castle Windsor (as well as Castle Core, and a whole set of facilities) has now been released. There are no major changes between final version and RC. The difference is some minor bug fixes, improved exception messages and some small improvements all over the place.

The packages are available now, on Nuget (with symbols), and via standard .zip download.

Last but not least — thank you to everyone who downloaded beta and release candidate and provided feedback. You guys rock.

Getting closer… Castle Windsor 3 RC 1

Posted 11/20/2011 4:14:31 AM at kozmic.pl

Few weeks later than originally expected but here it is – Castle Windsor 3.0 (along with its facilities and Castle.Core) achieved release candidate status.

There is one major new feature in this release: registration API gained ability to specify properties to ignore/require. There are some scenarios where that’s useful, for example where integrating with some 3rd party framework that forces you to inherit from a base class which exposes its dependencies as properties. Creating pass-through constructors for each inherited class can be mundane. In those cases you can simply mark those base class properties as required, in which case Windsor will not allow them to be resolved unless all base property dependencies are satisfied. PropertyFilter enum supports several other most common scenarios, and for advanced cases there’s an overload that gives you more control.

Container.Register(
    Classes.FromThisAssembly()
        .BasedOn<ICommon>()
        .Configure(c => c.Properties(PropertyFilter.RequireBase)));

To address performance hit at startup Windsor no longer enables performance counters by default. Now, you have to do it explicitly:

var container = new WindsorContainer();
var diagnostic = LifecycledComponentsReleasePolicy.GetTrackedComponentsDiagnostic(container.Kernel);
var counter = LifecycledComponentsReleasePolicy.GetTrackedComponentsPerformanceCounter(new PerformanceMetricsFactory());
container.Kernel.ReleasePolicy = new LifecycledComponentsReleasePolicy(diagnostic, counter);

Full changelog is included in the packages. Please, if possible, take the time to upgrade to this version and if you find any issues report them so that the final release is rock solid. If no major issues are found, the final release will be published in two weeks.

The binaries are available on Nuget right now, and soon on our website.

Windsor 3 beta 1 – dozen of Nuget packages and SymbolSource.org support

Posted 9/4/2011 3:48:58 AM at kozmic.pl

As promised, I released Nuget packages for beta 1 of Windsor 3. This is my first major rollout of Nuget packages, so please report any issues working with them.

Nuget and beta packages

Nuget is quickly evolving and getting more useful with each release. However one feature it’s missing right now is support for pre-release packages (this is coming in the next version).

This is not really a big deal, however it means there are a few things you should be aware of.

Recommended version

Since the new package is a pre-release, while I would really like for everyone to start using it immediately and report all issues they find, I quite understand that many people will rather prefer to stick to the last official version for the time being. To accommodate that the new packages are not made recommended versions, so your Nuget explorer will still point to the last stable (2.5.3) version if you search for Windsor, Castle.Core or any other pre-existing package.

If you go to command line and install one of the packages without specifying version number, it will install the latest, that is beta 1 version.

SymbolSource.org and debugging into Windsor

Folks at SymbolSource.org added recently support for Nuget (and OpenWrap as well) and the new Castle packages take advantage of that. What it gives you, is you can now easily debug into Windsor’s code, just like .NET framework reference source (there’s a simple guide at SymbolSource on how to do it).

After you’re all set you can step into any of Castle methods in your debugger and watch the magic happen. Very cool thing, even if I say so myself.

List of packages

Here’s the full list of v3 beta 1 packages (notice those are not all Castle packages, just those that were published as v3 beta 1 rollout of Windsor):

Castle.Core – Contains Castle.Core.dll which includes DynamicProxy, DictionaryAdapter, EmailSender, logging abstractions and some other goodies.
Castle.Core-log4net – Contains Castle.Services.Logging.Log4netIntegration.dll, that is implementation of Castle logging abstractions for log4net
Castle.Core-NLog – Contains Castle.Services.Logging.NLogIntegration.dll, that is implementation of Castle logging abstractions for NLog
Castle.Windsor – Contains Castle.Windsor.dll which has Windsor itself and two most commonly used facilities – Typed Factory facility and Startable facility.
Castle.LoggingFacility – Contains logging facility.
Castle.Windsor-log4net – Empty package that just installs logging facility and Castle.Core-log4net (and their dependencies obviously).
Castle.Windsor-NLog – Empty package that just installs logging facility and Castle.CoreNLog (and their dependencies obviously).
Castle.WcfIntegrationFacility – Windsor’s WCF facility.
Castle.SynchronizeFacility – Windsor’s Synchronize facility.
Castle.RemotingFacility – Windsor’s Remoting facility (extracted out of Castle.Windsor.dll)
Castle.EventWiringFacility – Windsor’s Event Wiring facility (extracted out of Castle.Windsor.dll)
Castle.FactorySupportFacility– Windsor’s Factory Support facility (extracted out of Castle.Windsor.dll)

I hope this will make it easier for everyone to test drive Windsor. And if you find any issues, have any suggestions or ideas, do not hesitate to bring them up, either on our google group, or issue tracker.

PropertyBagTextWriter (Stream into Dictionary)

Posted 8/18/2011 11:50:53 AM at honestillusion.com

It’s been too long since I posted since .NET code, and I’ve been itching to. (Actually, I really want to write more about politics, but I figured if I don’t show some code soon, I’m gonna lost my techy audience) Fortunately, I’ve got a backlog of things I’ve been meaning to write about. Today’s is the PropertyBagTextWriter.

The original purpose of this for a particular use in combination with Castle Monorail and Linq-2-Sql, but it has been made general purpose, so you may find a use for it in other environments.

Now, when Linq-2-Sql was still in beta, the DataContext object had a property which held, as a string, the SQL generated from the Linq query. As I was writing a Monorail website, I often assigned that property to a value in the PorpertyBag (which is just a IDictionary, not even a IDictionary<K,V> -- PropertyBag[“SQL”] = db.Log;), and write it in an HTML comment on the webpage, so I could see I was getting what I expected. However, the designer eventually realized that a string property wasn’t good enough, as the Linq query could produce several SQL statement, some of which would be based on the response from the earlier ones. So, they replaced it with a property which can be set to a TextWriter and have the SQL output written there. So, to use it the way I was before, I needed a TextWriter-ish object, which would set it’s output to a value in a Dictionary (db.Log = new PropertyBagTextWriter(“SQL”, PropertyBag); ) The important point here is that it’s self-contained. Once we set the property to the PropertyBagTextWriter object, we should never have to interact with it again. The value should just appear in the dictionary when it’s ready.

The code itself is fairly straightforward. Start by deriving a new class from StringWriter, which is usually the best way to create a customized TextWriter. That way, it’s handle the details of gathering and formatting the data from the stream, and all we have to deal with is the string at the end.

    class ProperyBagTextWriter : StringWriter
    {

Next, we’re going to need to know the dictionary the output will be stored in, and the key, so we accept those in the constructor, and hold on to them for later:

public ProperyBagTextWriter(string key, IDictionary bag)
{
    this.key = key;
    this.bag = bag;
}
string key;
IDictionary bag;

Then the key point: When we get a Flush() call, we save the text we gathered so far into the dictionary under that key:

public override void Flush()
{
    base.Flush();
    bag[key] = base.ToString();
}

However, since we can’t count on the Flush always being called when we need it, we’ll force a flush at other times, like during the Dispose() and after writing a line:

protected override void Dispose(bool disposing)
{
    base.Dispose(disposing);
    if (disposing)
        Flush();
}

public override void Write(char[] buffer, int index, int count)
{
    base.Write(buffer, index, count);
    Flush();
}

That all there is to it. Besides the Linq2Sql log, I’ve also used it for the output from a XSLT transformation.

Source Code: I’ve decided to get with the times, and create (well, actually “use”… I created it a while ago), a GitHub account. So, you can find this class, code from my future posts, and when I get around to it, code from my older post, at http://github.com/jamescurran/HonestIllusion

Share this post: Email it! | bookmark it! | digg it! | reddit!