Digging through the Castle source code look what I found in the "HowToBuild" file (note the last line):

Possible problem with 3.5
=========================
if you get the following error:
"The SDK for the 'net-3.5' framework is not available or not configured."
then you probably need to fix the sdkInstallRoot in your nant.exe.config file to point to the correct location in the registry
See the following article for more info:
http://www.timbarcz.com/blog/NantSetupForVisualStudio2008AndNet35.aspx

Looking through the file's history I can see that Ken Egozi is a pretty smart man. *wink* *wink*

Shhh...don't tell anyone but we don't unit test all of our code.  We're striving to get all developers and managers on board with unit testing but we're not there yet.  Despite our delinquency in writing tests one thing we do try our very best to do is keep mistakes from happening again.  If we find a bug in the system, before fixing it, we go and write a unit test for that problem.  We verify the test fails, the go and write the code that fixes it.  This recognizes that bugs will appear in the system, but once fixed we'll insulate ourselves from that bug happening again.

We had one such case last week.  We were getting a yellow-screen error after a bunch of commits by developers.  The error stemmed from a component in Windsor that did not have all of it's dependencies met.  In other words, we registered a component which relied on another component which was not registered.  We already had written a test to compile and test our Windsor configuration, however that test was not mature enough and needed some tweaking. 

In our application we leverage the new ASP.Net MVC.  We also take advantage of the ability to leverage an IoC container, Windsor, to create controller instances when a web request comes in.  When the application starts, we register all of the controllers in the application into Windsor using reflection.  Therefore our Windsor configuration at runtime is made up of two things, the XML configuration and the controllers which are registered on startup.  The "bug" here was that one of our controllers had a dependency on it that was not registered in Windsor.  When you ran the test by itself, the test would pass, since it was only loading up the components from the Windsor configuration.

Wanting to protect us in the future, we acknowledged there was something missing from our test and set out to find it.  To create the failing test was relatively simple.  All that we needed to do replicate in our test what we were doing at runtime.  Therefore we needed to register all implementers of IController, just like we do on application startup.  Below I've

Before:

               1: IWindsorContainer
container = new WindsorContainer("windsor.config.xml");

               2:  

               3:
              foreach (var
handler in container.Kernel.GetAssignableHandlers(typeof(object)))

               4: {

               5: Console.WriteLine("{0}\n\t-
{1}", handler.ComponentModel.Service, handler.ComponentModel.Implementation);

               6: container.Resolve(handler.ComponentModel.Service);

               7: }

After:

               1: IWindsorContainer
container = new WindsorContainer("windsor.config.xml");

               2:  

               3: var
assm = new HomeController(null).GetType().Assembly;

               4:
              //add
all controllers
            

               5:
              foreach (Type
type in assm.GetTypes())

               6: {

               7:
              if (typeof(IController).IsAssignableFrom(type)
&& !type.IsAbstract)

               8: {

               9: container.AddComponent(type.Name.ToLower(),
type);

               10: }

               11: }

               12:  

               13:
              foreach (var
handler in container.Kernel.GetAssignableHandlers(typeof(object)))

               14: {

               15: Console.WriteLine("{0}\n\t-
{1}", handler.ComponentModel.Service, handler.ComponentModel.Implementation);

               16: container.Resolve(handler.ComponentModel.Service);

               17: }

Now that this test is in place, I am much more confident that we won't see the error we were seeing in product again, we've got a test which warns us if something isn't quite right.  Our initial test didn't quite get it all right.  Mistakes/bugs in code will happen, hopefully few and far between, but when a bug does show up, go write a test that verifies the bug before going off an fixing it.  Then make the test pass, which should fix the bug.

Windsor will stitch together objects for you at runtime based on what components have been registered.  When you ask for an instance of an object from the Windsor/MicroKernel it will return the object using the constructor it can satisfy.

I ran into a problem the other day when I wanted to create an object that accepted three types, the third was a non-primitive that I didn't control.  Castle's website goes into some detail on this in their documentation on Windsor/MicroKernel:

                 1:
                <
                configuration
                >
              

                 2:  

                 3:
                <
                components
                >
              

                 4:
                <
                component
                id
                ="smtp.sender"
              

                 5:
                service
                ="Namespace.IEmailSender,
AssemblyName"
              

                 6:
                type
                ="Namespace.SmtpMailSender,
AssemblyName"
                >
              

                 7:
              

                 8:
                <
                parameters
                >
              

                 9:
                <
                port
                >10</port>

                 10:
                <
                host
                >smtphost</host>

                 11:
                </
                parameters
                >
              

                 12:
              

                 13:
                </
                component
                >
              

                 14:
                </
                components
                >
              

                 15:  

                 16:
                </
                configuration
                >
              

the problem I was running into is what if you have a third parameter, which isn't a primitive?  I have the following signature:

               1:
              public CommunicationGateway(string host, int port,
Encoding encoding)

               2: {

               3:
              this.host
= host;

               4:
              this.port
= port;

               5:
              this.encoding
= encoding;

               6: }

The example above fits quite nicely until I hit the third parameter.  How do I define what that third parameter should be in Windsor given that it's not a class that I control nor a primitive type? This felt like it should be easy, but I could not find the information I needed on the Castle website.  I got some help from Castle committer Dru Sellers.  In the end Dru pointed me to a very simple solution; register the type and pass it in using the service lookup notation, ${}

               1:
              <
              component
              id
              ="CommunicationGateway"
            

               2:
              service
              ="ABCCompany.ICommunicationGateway,
ABCCompany"
            

               3:
              type
              ="ABCCompany.CommunicationGateway,
ABCCompany"
              >
            

               4:
              <
              parameters
              >
            

               5:
              <
              host
              >#{Host}</host>

               6:
              <
              port
              >#{Port}</port>

               7:
              <
              encoding
              >${Encoding}</encoding>

               8:
              </
              parameters
              >
            

               9:
              </
              component
              >
            

               10:  

               11:
              <
              component
              id
              ="Encoding"
            

               12:
              service
              ="System.Text.Encoding,
mscorlib"
            

               13:
              type
              ="System.Text.UTF8Encoding,
mscorlib"
              >
            

               14:
              </
              component
              >
            

You can see from above that I'm registering a component with the service System.Text.Encoding and supplying UTF8Encoding as the implementation.  Now I can use a strongly-typed System.Text.Encoding object and have it configurable in my Windsor Configuration, much more elegant than using a string (primitive-type) and hoping it works. 

Thanks Dru!