Friday, April 20, 2007
I noticed that Ivan posted a list of tutorials etc. on his blog... I think it's worth also adding that there is a site dedicated to these kinds of resources, as well as snippets, recipes etc.  - it's still in it's infancy, but I think it will end up being quite invaluable as a resource for castle project users (here's hoping at any rate!)

http://using.castleproject.org/

posted @ Thursday, April 19, 2007 9:19:00 PM (New Zealand Standard Time, UTC+12:00)    Comments [2] | Trackback |
 Thursday, April 19, 2007
So the first 9 posts are up for the container tutorial series...  but I haven't made much mention of what can be done to play around with the windsor container yourself while reading this series.

Well first-off ... my thoughts on getting started with the Castle project are generally practical, first off I think it's worth grabbing the second release candidate - check out what castle can do, have a general play, maybe try to generate a monorail project and get it working... and then ... well I would probably uninstall it, and grab the latest cut of the castle project and contributed projects from svn and build it yourself using nant.

This gives you opportunities to use all the "new stuff" that gets added day by day (as well as bug fixes) but also ensures your actually capable of building and contributing patches for any issues you discover.

But that's a bit of an ask for someone experimenting, especially if you don't know anything about svn... so essentially for playing around with the basics of the windsor container, you only need 4 Castle assemblies from the bleeding edge, and I'll give them to you:

simple_container_references.png

And to make life easy I included those assemblies in a folder called "SharedLibs" as part of the following zip file, which contains the code for the first 9 parts... I'll do another code drop at the end of the container tutorials to round out the series for the sake of posterity... but everything you need for the first 9 tutorials is here:

Files for Parts 1 thru 9

Good Times ;o)


posted @ Thursday, April 19, 2007 10:31:40 AM (New Zealand Standard Time, UTC+12:00)    Comments [4] | Trackback |
9_constructor_injection.png

Constructor injection - so far inadvertantly we've been using setter inject to get our configuration information into our components... but you can also use constructors... the useful aspect of constructors is that it makes those parameters compulsory...

So lets take a look at the code for this post, first off there's an interface for a service which takes care of encoding a string for us:

public interface IEncoder

{

    string Encode(string source);

}


And then we have no classes which implement this service, one we can use when testing to not encode things at all - and another which encodes a string using our particularly strong "silly" encryption...

NullEncoder.cs

public class NullEncoder : IEncoder

{

    public string Encode(string source)

    {

        return source;

    }

}


SillyEncoder.cs

public class SillyEncoder : IEncoder

{

    private char[] _mixedUp = "YACBDFEGIHJLKMONPRSQTUWVXZ".ToCharArray();

 

    public string Encode(string source)

    {

        string upperSource = source.ToUpper();

        char[] encoded = new char[source.Length];

        for (int i = 0; i < encoded.Length; i++)

        {

            encoded[i] = MapCharacter(upperSource[i]);

        }

        return new string(encoded);

    }

 

    private char MapCharacter(char ch)

    {

        if ((ch >= 'A') && (ch <= 'Z'))

        {

            return _mixedUp[ch - 'A'];

        }

        return ch;

    }

}


When then have a class for sending messages (currently we just send it to the console, so we can print them out and paste them onto the back of postcards) ... so lets have a look at that class:

public class SecretMessageSender

{

    private readonly IEncoder _encoder;

    private readonly string _from;

 

    public SecretMessageSender(string from, IEncoder encoder)

    {

        _from = from;

        _encoder = encoder;

    }

 

    public void SendMessage(string to, string body)

    {

        Console.WriteLine("to: {0}\r\nfrom: {1}\r\n\r\n{2}", to, _from, _encoder.Encode(body));

    }

}


Notice the lack of default constructor, and that the constructor also takes an instance of type IEncoder... now Castle is smart enough to do two things for us:
  • Throw an exception if we try to get an isntance of SecreteMessageSender without having set the from configuration parameter.
  • Find the default implementation of the IEncoder registered in the container, and to supply that as the value for the second argument in the constructor.
So lets have a look at the application itself:

static void Main(string[] args)

{

    WindsorContainer container = new WindsorContainer(new XmlInterpreter());

 

    SecretMessageSender sender = container.Resolve<SecretMessageSender>();

 

    sender.SendMessage("hammet", "castle is great!");

 

    Console.Read();

}


And finally our configuration:

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

    <components>

      <component id="encoder.silly"

                service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"

                type="IoC.Tutorials.Part9.SillyEncoder, IoC.Tutorials.Part9" />

 

      <component id="encoder.null"

                service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"

                type="IoC.Tutorials.Part9.NullEncoder, IoC.Tutorials.Part9" />

 

      <component id="messageSender"

                type="IoC.Tutorials.Part9.SecretMessageSender, IoC.Tutorials.Part9">

        <parameters>SecretMessageSender

          <from>alex@bittercoder.com</from>

        </parameters>

      </component>

 

    </components>

  </castle>

 

</configuration>


So you can see we've registered both implementations of the encoder, with the silly encoder being first - so as mentioned in the last part - this will be the default - and we also register our message sender (with the required from parameter)... so what happens when we run it:

to: hammet
from: alex@bittercoder.com

CYSQLD IS ERDYQ!


Cool... but what if wanted to send an unencrypted message... well we have a few options:
  • Swap the order in which the implementations are registered
  • Remove / comment out any implementations we don't want (so comment out the silly encoder)
  • Or reference the implementation we specifically want to wire up to, using it's identifier...
So lets have a look at the last one...

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

    <components>

      <component id="encoder.silly"

                service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"

                type="IoC.Tutorials.Part9.SillyEncoder, IoC.Tutorials.Part9" />

 

      <component id="encoder.null"

                service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"

                type="IoC.Tutorials.Part9.NullEncoder, IoC.Tutorials.Part9" />

 

      <component id="messageSender"

                type="IoC.Tutorials.Part9.SecretMessageSender, IoC.Tutorials.Part9">

        <parameters>SecretMessageSender

          <from>alex@bittercoder.com</from>

          <encoder>${encoder.null}</encoder>

        </parameters>

      </component>

 

    </components>

  </castle>

 

</configuration>


Notice the way the parameter is formatted - instead of the markup for a property reference which starts with a hash (#) we start service references with a dollar sign ($) and then surround the components identifier with braces.

And the results of running the app now:

to: hammet
from: alex@bittercoder.com

castle is great!


And thats our first look at constructor injection... we will revisit constructor injection again in later posts, however the next part will look at setter injection.
posted @ Thursday, April 19, 2007 9:37:05 AM (New Zealand Standard Time, UTC+12:00)    Comments [0] | Trackback |

8_implementations_by_key.png
So far we've looked at registering one implementation for any one service, you could call them the "default" implementation, because it's the implementation the container returns when you ask for that service... but your not limited to only having one implementation registered, and the way to do this is by giving each implementation that's registered a unique key.

There are many reasons for doing this... but in this example we'll look at one reason - because we want to vary the configuration info used...

So here's our component's code:

public class FileReader

{

    private string _fileName;

 

    public string FileName

    {

        get { return _fileName; }

        set { _fileName = value; }

    }

 

    public string ReadToEnd()

    {

        return File.ReadAllText(_fileName);

    }

}


It's a simple class which lets us read the contents of a file as many times as we like... so we're going to try registering it twice, with different configurations (and different identifiers) in the container.

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

    <components>

      <component id="reader.file1" type="IoC.Tutorials.Part8.FileReader, IoC.Tutorials.Part8">

        <parameters>

          <FileName>file1.txt</FileName>

        </parameters>

      </component>

      <component id="reader.file2" type="IoC.Tutorials.Part8.FileReader, IoC.Tutorials.Part8">

        <parameters>

          <FileName>file2.txt</FileName>

        </parameters>

      </component>

    </components>     

  </castle>

 

</configuration>


So far so good, lets have a look at the app itself - notice that the file1Reader and file2Reader instances are "resolved" with an extra parameter - which is the id, or key, used to select a particular implementation... but what about the default instance, which reader will that be?

static void Main(string[] args)

{

    WindsorContainer container = new WindsorContainer(new XmlInterpreter());

 

    FileReader defaultReader = container.Resolve<FileReader>();

    FileReader file1Reader = container.Resolve<FileReader>("reader.file1");

    FileReader file2Reader = container.Resolve<FileReader>("reader.file2");

 

    Console.WriteLine("Default contents: {0}", defaultReader.ReadToEnd());

    Console.WriteLine("File1 contents: {0}", file1Reader.ReadToEnd());

    Console.WriteLine("File2 contents: {0}", file2Reader.ReadToEnd());

 

    Console.Read();

}


And here's the results of running the program:

Default contents: This is the contents of file 1.
File1 contents: This is the contents of file 1.
File2 contents: This is the contents of file 2.


So you can see that file1Reader and defaultReader are the same - and file1Reader was the first FileReader to be registered in the container -and that's the rule, the first one registered is the default... which is another example of convention over configuration with Castle, rather then having to explicity denote which is the default with some more xml noise.

Though with a little thinking you can find plenty of ways to access implementations by key to solve certain problems, for the unimaginative ... how about an application where you can provide a uri to send plain text messages to ... and depending on the scheme you need to find an implementation that can do the work of sending the message.

You have a bunch of destinations, addressed by Uri...
  • file://c:/temp/log.txt
  • ftp://ftp.google.com/log.txt
  • http://www.bittercoder.com/SimpleMessageService.aspx
  • fax://64215559555
And then you can just register the implementations/schemes you wish to support...
  • messageSender.file
  • messageSender.ftp
  • messageSender.http
  • messageSender.fax
And then look them up as required, using something like

Uri uri;

// blah blah blah

string key = "messageSender."+ uri.Scheme;

if (container.Kernel.HasComponent(key))

{

    ISender sender = container.Resolve<ISender>(key);

    // send the message at this point...

    sender.SendMessage("hi there");

}

else

{

    // no implementation registered...

    throw new NotImplementedException("no sender registered for scheme: " + uri.Scheme);

}


Personally I wouldn't do this ;o) but there's certainly no technical reason why you couldn't... notice how we check that a component is registered for that key - we could just let the container throw an exception... but then we wouldn't know how to check that a container has a certain key registered in it, would we!

The next part will be on constructor injection... and following that setter injection.
posted @ Thursday, April 19, 2007 7:23:14 AM (New Zealand Standard Time, UTC+12:00)    Comments [0] | Trackback |
 Wednesday, April 18, 2007

So I've decided to do a quick little series on the windsor container - all up It'll probably cover 15 to 20 posts... each one should be very short, covering some small concept... just a little nugget.

This series will be a little different then most discussions on IoC and containers... rather then get in your face with concepts like dependency injection, and encouraging testability, it's just going to focus on the container itself, and the ways you can use it... I'm not sure if it'll be of any value, but If nothing else to gets me back into blogging regularly.

The first 7 parts are already up:

I'll be posting them in batches... so the series should be finished within a week.

posted @ Tuesday, April 17, 2007 7:51:40 PM (New Zealand Standard Time, UTC+12:00)    Comments [4] | Trackback |
 Tuesday, April 17, 2007
7_switching_implementations.png
So this time we're going to look at how you can not only change configuration for a component at runtime, but actually change which component is doing the work for us... powerful stuff :)

So the "trick" here is to abstract out what features we expect our component to support from it's implementation, and stuff those into an interface... so in this case I have an idea for a simple service which lets us get the "message of the day" - so lets look at my interface:

public interface IMessageOfTheDay

{

    string GetMessageOfTheDay();

}


Now we have two implementations of this service, one that lets us have a static message set via configuration:

public class StaticMessageOfTheDay : IMessageOfTheDay

{

    private string _message;

 

    public string Message

    {

        set { _message = value; }

    }

 

    public string GetMessageOfTheDay()

    {

        return _message;

    }

}


And another, which goes to wiki quotes and grabs the quote of the day:

public class WikiQuotesMessageOfTheDay : IMessageOfTheDay

{

    public string GetMessageOfTheDay()

    {

        WebClient client = new WebClient();

        string content = client.DownloadString("http://en.wikiquote.org/wiki/Main_Page");

 

        string toFind = "<div style=\"background: #fff5f5\">";

        int start = content.IndexOf(toFind) + toFind.Length;

        int length = content.IndexOf("<a", start) - start;

 

        return content.Substring(start, length);

    }

}


so - our program is pretty simple:

private static void Main(string[] args)

{

    WindsorContainer container = new WindsorContainer(new XmlInterpreter());

 

    IMessageOfTheDay motd = container.Resolve<IMessageOfTheDay>();

 

    Console.WriteLine("MOTD: {0}", motd.GetMessageOfTheDay());

 

    Console.Read();

}


And so how do we swap between implementations, well we need to introduce an additional attribute to our components configuration called "service" where we specifiy what service our component implements... in this case it will be "IMessageOfTheDay" - so heres the configuration when using the Static MOTD class:

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

    <components>

      <component id="motd.service"

                service="IoC.Tutorials.Part7.IMessageOfTheDay, IoC.Tutorials.Part7"

                type="IoC.Tutorials.Part7.StaticMessageOfTheDay, IoC.Tutorials.Part7">

        <parameters>

          <message>Welcome to my container tutorials</message>

        </parameters>

      </component>

    </components>

  </castle>

 

</configuration>


And running the program gives us:

MOTD: Welcome to my container tutorials

But we can now swap to a different component with the same service at run-time, and get a different implementation... here's how that looks:

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

 

    <components>

      <component id="motd.service"

          service="IoC.Tutorials.Part7.IMessageOfTheDay, IoC.Tutorials.Part7"

          type="IoC.Tutorials.Part7.WikiQuotesMessageOfTheDay, IoC.Tutorials.Part7" />

    </components>

  </castle>

 

</configuration>


And now running the program gives us:

MOTD: Man is not an end but a beginning. We are at the beginning of the second week. We are children of the eighth day.

A quote from Thorton Wilder - exciting huh, this seperation between interface and implementation is what makes doing so many cool things with an Inversion of control container possible... soak up the idea.

Next time we'll take a look at getting different implementations by using their "key" - have you been wondering what the "id" attribute is for in our component definitions?? Well wonder no more.
posted @ Tuesday, April 17, 2007 11:34:46 AM (New Zealand Standard Time, UTC+12:00)    Comments [0] | Trackback |
6_switching_lifestyles.png
Switching lifestyles is the theme of this post... so what's that all about?

Well first off - what is a lifestyle, in basic terms it specifies how many instances will be available at any one time from the container - so at the one extreme we have components with a transient lifestyle, where any requests from those components will return new instances - and at the opposite end of the spectrum we have singleton components, where there is only one instance for the whole container - there are other types of lifestyle, but we'll leave those for another post.

So first off - castle is all about convention over configuration, and by convention a component in the container is a singleton... so in this example we'll look into ways in which you can switch a components lifestyle to being transient.

First off, heres our component:

public class AddingService

{

    private int _total = 0;

 

    public void AddAmmount(int ammount)

    {

        _total += ammount;

    }

 

    public int Total

    {

        get { return _total; }

    }

}


It lets us add stuff... how neat is that... lets see our program:

private static void Main(string[] args)

{

    WindsorContainer container = new WindsorContainer(new XmlInterpreter());

 

    AddingService sheepCounted = container.Resolve<AddingService>();

    AddingService catsHerded = container.Resolve<AddingService>();

 

    sheepCounted.AddAmmount(10);

    sheepCounted.AddAmmount(50);

 

    catsHerded.AddAmmount(3);

    catsHerded.AddAmmount(12);

 

    Console.WriteLine("You have counted {0} sheep and herded {1} angry cats", sheepCounted.Total,

                      catsHerded.Total);

 

    Console.Read();

}


And if we run it:

You have counted 75 sheep and herded 75 angry cats

That doesn't seem right - our service is retaining a count, so we want a fresh instance of the class every time we request it - which means we should shift our component to the "transient" lifestyle - lets have a go at doing it with configuration, by adding the lifestyle attribute to the components definition.

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

    <components>

      <component id="adding.service" type="IoC.Tutorials.Part6.AddingService, IoC.Tutorials.Part6" lifestyle="transient" />

    </components>

  </castle>

 

</configuration>


And now if we run it again:

You have counted 60 sheep and herded 15 angry cats

That looks a bit better... but I propose that in many cases when your writing a component you know what it's lifestyle should be, before it's ever registered in a container - for instance in this case this class should always be transient, so we can actually decorate the class with a "Transient" attribute and can skip having to put the lifestyle in the configuration, this is how that would look:

[Transient]

public class AddingService

{

    private int _total = 0;

 

    public void AddAmmount(int ammount)

    {

        _total += ammount;

    }

 

    public int Total

    {

        get { return _total; }

    }

}


There are other lifestyles available to use - it's worth having a look through the castle wiki for more details... and we'll probably cover them in another post.

In the next part we will cover switching out implementations of components themselves.

posted @ Tuesday, April 17, 2007 11:12:30 AM (New Zealand Standard Time, UTC+12:00)    Comments [2] | Trackback |

5_config_parameters.png
So in this part we're going to look at configuration parameters - parameters let you consolidate or seperate individual configuration parameters away from the components themselves, in this case we are going to create 2 config files, one for parameters to use in the live system, and the other for parameters in the debug system.

The advantage with this approach is that you don't have to duplicate the component registrations, you can leave those in one place (for the example, we just put them in the app.config)... so lets start by looking at our two sets of property configurations...
  • properties-debug.config
  • properties-live.config
properties-debug.config

<configuration>

  <properties>

    <configName>Debug</configName>

  </properties>

</configuration>


properties-live.config

<configuration>

  <properties>

    <configName>Live</configName>

  </properties>

</configuration>


And now the app.config...

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle> 

    <components>

      <include uri="file://properties-debug.config" />

      <!--<include uri="file://properties-live.config" />-->

 

      <component id="whatConfig.service" type="IoC.Tutorials.Part5.WhatConfigurationService, IoC.Tutorials.Part5">

        <parameters>

          <Configuration>#{configName}</Configuration>

        </parameters>

      </component>

    </components>

  </castle>

 

</configuration>


Notice how the components configuration value has a hash (#) and some braces surrounding the word "configName" - that causes castle to look up the value of the property by the same name (which we declared in the property config file).

The application code is the same as part 4.

A common approach when working with developers who may need different configurations is to <include/> a file called say properties.config that contains all the configuration values that need to change between machines, and to not check that into source control... Be sure to also keep a "master" copy of the properties, say "master-properties.config" which provides a template for developers to create their own configuration (it's not a bad place to stick the instructions for doing this as well).


posted @ Tuesday, April 17, 2007 10:30:56 AM (New Zealand Standard Time, UTC+12:00)    Comments [0] | Trackback |
4_switching_configs.png
So, we have all this stuff in a configuration file... but what if we have two sets of configuration we want to swap between - perhaps one for test and one for live... well here's one way of doing it with the Windsor container.

So this is our component, we use it for demonstrating which configuration is loaded:

public class WhatConfigurationService

{

    private string _configuration;

 

    public string Configuration

    {

        get { return _configuration; }

        set { _configuration = value; }

    }

}


Now here's the applications code:

private static void Main(string[] args)

{

    WindsorContainer container = new WindsorContainer(new XmlInterpreter());

 

    WhatConfigurationService whatConfiguration = container.Resolve<WhatConfigurationService>();

 

    Console.WriteLine("Configuration: {0}", whatConfiguration.Configuration);

 

    Console.Read();

}


So we do this by seperating our configuration sets into different files... so we create two configuration files, called:

  • container-debug.config
  • container-live.config
And here's what they look like:

container-debug.config

<configuration>

    <components>

      <component id="whatConfig.service" type="IoC.Tutorials.Part4.WhatConfigurationService, IoC.Tutorials.Part4">

        <parameters>

          <Configuration>Debug</Configuration>

        </parameters>

      </component>

    </components>

</configuration>


container-live.config

<configuration>

  <components>

    <component id="whatConfig.service" type="IoC.Tutorials.Part4.WhatConfigurationService, IoC.Tutorials.Part4">

      <parameters>

        <Configuration>Live</Configuration>

      </parameters>

    </component>

  </components>

</configuration>


So if we've moved configuration into seperate files, how does the container know about them.... well, we use includes... so here's our main configuration file now:

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

    <!--<include uri="file://container-debug.config" />-->

    <include uri="file://container-live.config" />

  </castle>

 

</configuration>


So you can see that to shift between the debug and live configurations we just swap between including one configuration and another...

And when live is uncommented, running the program gives us this output:

Configuration: Live


There are other ways to achieve the same thing, but this is often the easiest to understand... also take careful note of that uri attribute on the include element... you don't just have to use the file:// scheme - you can include resources (embedded in your assemblies) or extend the resource subsystem with additional support for your own types of resources - but before you do, be sure to have a look at the list of out of the box possibilities here.

One question that was asked about during Architecture Camp was how container configuration could be synchronized between multiple servers, and includes provide one possibility, because you can place your shared configuration on a network share, or implement your own special resource type, that could for instance get the configuration from a webservice.

Next time we'll look at introducing configuration parameters, which is another way to deal with the problems of having to switch between configs at runtime - and can make your configuration easier to read and maintain too.

posted @ Tuesday, April 17, 2007 9:53:36 AM (New Zealand Standard Time, UTC+12:00)    Comments [0] | Trackback |
3_more_config_dictionaries.png

So in this part we look at creating a component which has a dictionary which gets configured... in this case we're creating a little service to handle word substitutions...

So lets have a look at the service:

public class AliasService

{

    private Dictionary<string, string> _aliases;

 

    public Dictionary<string, string> Aliases

    {

        get { return _aliases; }

        set { _aliases = value; }

    }

 

    public string Evaluate(string term)

    {

        if (_aliases == null) return term;

 

        while (_aliases.ContainsKey(term))

        {

            term = _aliases[term];

        }

 

        return term;

    }

}


And the application code that uses the service:

static void Main(string[] args)

{

    WindsorContainer container = new WindsorContainer(new XmlInterpreter());

 

    AliasService aliasService = container.Resolve<AliasService>();

 

    string sentence = "a dog ate my homework";

 

    foreach (string word in sentence.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries))

    {

        Console.Write("{0} ", aliasService.Evaluate(word));

    }

 

    Console.Read();

}


Our component is again registered without any parameters, lets run it and see what pearls of wisdom it can share:

a dog at my homework

Hmm... I'm not sure that's a great excuse for late delivery... let's do some configuration and try again:

<configuration>

 

  <configSections>

    <section name="castle"

        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />

  </configSections>

 

  <castle>

    <components>

      <component id="aliases.service" type="IoC.Tutorials.Part3.AliasService, IoC.Tutorials.Part3">

        <parameters>

          <Aliases>

            <dictionary>

              <entry key="dog">duck</entry>

              <entry key="ate">broke</entry>

              <entry key="homework">code</entry>

            </dictionary>

          </Aliases>

        </parameters>

      </component>

    </components>

  </castle>

 

</configuration>


So, you can see we map keys to values via an entry key... and here's the result:

a duck broke my code

You may need to tweak the mappings, depending on what you actually broke...

Now at this point you might be wondering just how the strings are getting converted into strongly typed values for the last 3 parts - and to be honest, you won't need to know most of time, just do what "seems" right and it'll probably work... but when it doesn't, check out the castle projects wiki topic on component parameters, configuration and type converters.
posted @ Tuesday, April 17, 2007 9:14:30 AM (New Zealand Standard Time, UTC+12:00)    Comments [2] | Trackback |
Search
FeedCount

Tags...