• Castle monorail brail view template

    I finally spent two minutes to create a view.brail VS template today. It’s really basic, but at least I won’t end up with a class definition every time I try to add a new view. Below is the zip file, just drop in into My Documents\Visual Studio 2005\Templates\ItemTemplates.

    View.zip (5.12 KB)

  • Updates to AwsS3Library – Bucket contents support

    Posted updates and fixes to the AwsS3Library. Added support for AwsBucket Contents to be parsed when getting a bucket.

    AwsBucket bucket = _service.Get(new AwsBucket("somebucket"));
    foreach (AwsObjectKey awsObjectKey in bucket.AwsObjectKeys)
    Console.WriteLine("Object Key " + awsObjectKey.Key);


  • OpenId Authentication In Castle Monorail with ExtremeSwank OpenID Consumer

    I spent some time today setting up OpenId in Monorail using ExtremeSwank OpenId consumer library. I went with a view component that can be on every page and a login controller to handle the authenticate and logout functions. This code is mostly a mix of the ExtremeSwank sample code and monorail sample code and probably shouldn’t be used in a production environment.

    Anyway, we’ll start with the controller. It has three methods, Index, Authenticate, and Logout. The Index is just an empty action to explain OpenId to those who may not have experience with it. Authenticate takes the OpenId URL provided by the user to authenticate.  We store that in the session and pass to the consumer. Then we call BeginAuth which will process the request as long as the URL is correct. If not I render the Index view.

    public void Authenticate(string openIdUrl)
    try { OpenIDConsumer consumer = new OpenIDConsumer();
    consumer.Identity = openIdUrl;
    Session[OPENID_LOGIN] = consumer.Identity;
    consumer.ReturnURL = Context.UrlReferrer;
    catch (Exception e)
    PropertyBag["message"] = "Login attempt failed.";
    ly, I have the Logout method which just removes the OpenIdUser object from the session.<!-- code formatted by http://manoli.net/csharpformat/ -->
    public void Logout()
    Session[OPENID_USEROBJECT] = null;

    Next I have the ViewComponent which checks to see if the user is authenticating, authenticated, or not. I check for the OpenIDUser in the session first, if it finds that, then the user is authenticated. Otherwise, it creates a OpenIdConsumer object which looks at the state of authentication and executes accordingly, rendering either the default URL box or the logout link.

    public override void Render()
    OpenIDUser user = Session[LoginController.OPENID_USEROBJECT] as OpenIDUser;
    if (user != null)
    else { OpenIDConsumer consumer = new OpenIDConsumer();
    switch (consumer.RequestedMode)
    case RequestedMode.IdResolution:
    consumer.Identity = (string)Session[LoginController.OPENID_LOGIN];
    if (consumer.Validate())
    user = consumer.RetrieveUser();
    Session[LoginController.OPENID_USEROBJECT] = user;
    else { RenderLoginFailed(); } break;
    case RequestedMode.CancelledByUser:
    eded to add the appropriate views, but thats mostly all that's needed for this simple setup. <br><p></p>
  • How to test a mocked object when that object requires an attribute

    Today I needed to unit test a method that checked for and required a specific attribute on the class. I ended up with a fairly simple solution, the decorator pattern. Simply create a decorator for the type that needs the attribute, put the attribute on the decorator. Pass you mocked class to a new instance of the decorator when you pass to the method being tested. I sounds like more work then it is, of course it may not always make sense to go this route. Anyway, here’s the code.

    using NUnit.Framework;
    using NUnit.Framework.SyntaxHelpers;
    using Rhino.Mocks;

    namespace MockingClassesWithRequiredAttributes
    public class Class1
    public void Test()
    MockRepository mocks = new MockRepository();
    IRun mockedRun = mocks.DynamicMock<IRun>();
    using (mocks.Record())
    using (mocks.Playback())
    IRequireCategoryAttribute(new MockDecorator(mockedRun));

    static void IRequireCategoryAttribute(IRun run)
    object[] attributes = run.GetType().GetCustomAttributes(
    typeof(System.ComponentModel.CategoryAttribute), false);
    Assert.That(attributes.Length, Is.GreaterThan(0));

    class MockDecorator : IRun
    private readonly IRun run;

    public MockDecorator(IRun run)
    run = run;

    public void Run()

    public interface IRun
    void Run();

    One downside to this approach is the MockDecorator class that is just for testing. Any other approaches you’ve used?

  • Circuit City Sucks [rant]

    Warning: off topic rant, sorry.

    If you are going to buy anything from Circuit City be warned that you will be dealing with either lying

    or ignorant and lazy sales people and rude customer service.

    Recently on two different occasions I bought a product based on what the sales

    person told me and both times they were completely wrong.

    The first

    time was regarding a Sony handy-cam, they had two models, one was the DCR-SR82 (with a 60 Gig drive) and a DCR-SR42

    (with a 30 Gig drive). The sales staff claimed they were the same

    except for the drive size, which is completely false. I found this out

    after getting home, and reading the manual. It turns out Sony

    also has a DCR-SR62

    which is the same as the 82 with a smaller drive. One huge difference, among many,

    is that the 42 doesn’t record in wide screen format. So I took it back

    and had to get the manager of the store to issue a refund. Which he

    finally did after talking to the head camera guy who confirmed my

    claims. End result: bought the SR62 elsewhere (online).

    I’ve shopped at Circuit City a lot in the past, and so I thought, maybe the sales

    person was just new or something. So, I wanted some speaker mounts for my front

    speakers and I gave Circuit City another shot. When asked if I need

    help, I ask if the speaker mounts I’m looking at will fit

    my speakers and proceeded to show the sales guy which speakers I have

    (bought from them). He say confidently that they will work with those

    speakers. I get home and surprise they don’t. So today I took them back

    with the intention of getting the right ones. When I returned them, I

    told the CSR

    that these don’t fit my speakers, even after showing the sales guy which speakers

    I own. He says “That sucks. You should yell at him.” in a very

    sarcastic, I don’t give a shit, way. I was shocked to be treated so

    poorly. So, I’m done with Circuit City. It’s right on it’s way to being

    the next CompUSA.

    Too bad really, because at one point they were much better then Best Buy

    (the worse electronics store ever), and I bought a lot from them then.

    Circuit City sucks, don’t buy from them.

  • IoC smell: Having IContainerAccessor as a dependency.

    Looking back, it should have been an obvious thing to not do, but it wasn’t. I wanted to get access to the container and so I made IContainerAccessor a dependency for my class. The I added that to the container. The Main problem was that the IContainerAccessor interface was implemented on the class that also created the container. So, after startup I had two containers, one I created for the application and one that container created when the IContainerAccessor was created.

    Okay, there are other ways to implement the IContainerAccessor, but is that what I really needed? No, I really needed a way to create a specific kind of component. Maybe like a factory of some sort. Oh, yea the factory pattern is already sitting around waiting to be used. And it was a good solution here.

    That makes me think, for most cases where you want the container directly, there is a better solution waiting to be used.

  • Prefer Equals over operator== because generic types will not behave how you expect

    I stumbled across this unit testing some Immutable model objects. I’m overriding equals on these object and as so thought, how about I create a generic method to test equality? Sounded like a good idea, got rid of some duplicate code, made sure I’m testing all the variations on each object. Then my tests Failed! WTF? It turns out that using == on Generic Type objects is a bad idea, even it you’ve provided you own operator==! Even if you’ve implemented the IEquatable interface!

    This is bad:

    private static void TestGeneric<T>(T first1, T second1) where T:class 
    Console.WriteLine("{0} == {1} is {2}", first1, second1, IsTrue(first1 == second1));

    The compiler will emit IL that does two odd things, IMO. First, box’s the args first1 and first2. That’s a waste as they are constrained to be classes. Second it’s calling the IL method ceq (check equals). Why doesn’t it call Equals()? I’m guessing there are reasons for this, as it’s the same behavior in 3.5. Maybe if you meant to call Equals you should have?

    This is good:

    private static void TestGeneric<T>(T first1, T second1) where T:class 
    Console.WriteLine("{0} Equals {1} is {2}", first1, second1, IsTrue(first1.Equals(second1)));

    The above code won’t box the objects and it will call your overridden Equals method as expected. I know it’s been said before, but alway use the Equals method!

    One more interesting thing with the class constraint you can’t use the == syntax. I guess because once the box and class ceq it will break operator== for value types.

    Worse is that if your type constraint is a specific class it will allow and call the operator== method but only on that class so any subclass that are passed in will use the base classes operator== for the compare.

    Full code to see this in action is attached:

    Program1.cs (2.38 KB)