• Getting dasBlog and Castle.MonoRail to work together

    Ok, it’s not really about getting dasBlog to work with MonoRail, but really remembering that web.config has a cascading effect on sub applications in IIS. I had two bugs today the first of which took a long time to find, but both related to the root web.config having entries that caused problems in the sub application (dasBlog in this case).

    The first issue, for some reason I had the domain attribute in the forms authentication section set to / in the root web.config. Not sure why it was set like that, but apparently MonoRail overrides the domain value when setting cookies, while dasBlog doesn’t. This has the effect of not being able to log in to dasBlog, but not producing any errors, and in fact it says the login was a success. However, no cookie is issued. Removing the domain attribute fixed this problem.

    The second issue was regarding httpModules, in this case MonoRail’s routing module. This caused problems by requiring Castle dll’s be copied to the blogs bin directory, but more importantly it caused the FreeTextBox control to break and the blogging.aspx page to break because in these cases the files didn’t exists on disk and so (I think) the routing engine kicked in, though not setup on this application and missing dependencies, it failed. The fix for this, also easy and strait forward, is to remove the routing module from the blog application. To do that, you can just add a remove tag to the httpModules config like:

    <httpModules>
      <remove name="routingEx"/></httpModules>

    Both issues were simple enough, but not very obvious at the time.

  • CloudSH.com is in Alpha!

    CloudSH.com went into alpha last night, read more about it here.

  • Thoughts about 3rd party libraries and a projects build

    One thing I’m going start doing when starting a new project is to initially create a directory for compiled 3rd party libraries in the new projects root. Maybe one for debug builds and one for release builds. Doing this will save a lot of time later, one is always created later in the projects lifecycle, but then it requires resetting all the references in the build system and the project files. This is important for building the project on a different box anyway (like for continuous integration). I think this gets really important when working off an OSS projects trunk source code so the working build always has the correct OSS build.

  • My Startup Life [Review]

    51W7RJzp3YL._SL160_

    I just finished reading My Startup Life by Ben Casnocha. It an interesting and enjoyable read. It’s a mix of his story and insights and learnings from along the way. The insights and learnings are in side bars, which I found distracting. I might have enjoyed the story first and then then insights second. But I think a little more detail in the story and less or no sidebars would have been better. Anyway, I’d recommend it for anyone with an entrepreneurial streak. I’d give it 3/5 for a great story, good content and an okay mixing of the two.

  • Prototype classes and bind

    I’m working with the Prototype JS library classes, which I’m really liking. But I ran into one stumbling block, Binding. In JS the scope in which your function can be called can change and as such the ‘this’ object can change. The main places this can happen is call back functions for events or anytime anonymous methods are used. Justin Palmer explains it really well here.

    $(‘console’).observe(‘click’, prompt.focusLine.bindAsEventListener(prompt));

    The above will bind the focusLine method to the _prompt object when the event callback is fired. The same thing applies for events within a custom defined Class.

  • Facebook.NET Configuration Section

    I’m checking out the Facebook.NET libraries, and find the documentation to be very lacking. I could be looking in the wrong places. Anyway, to setup the configuration section, you need to reference the FacebookNET.Web.dll. Then in your config file add a section entry to the configSections tag like:

    <section name="facebook" type="Facebook.Web.Configuration.FacebookSection, FacebookNET.Web" allowDefinition="MachineToApplication"/>

    Then add the Facebook section with your info to the configuration tag:

    <facebook>
        <application name="Facebook.NET App" apiKey="[App Key]" secret="[Secret]"/>
    </facebook>

    That’s it. Now you can access that info from code like:

    var fbSection = (FacebookSection)ConfigurationManager.GetSection("facebook");
    var secret = fbSection.Applications["Facebook.NET App"].Secret;
  • Castle microkernel Shows It’s strength

    I’m a big fan of the CastleProject.org stack, but the MicroKernel really shows it’s strength when you need to do a couple of custom things, and find out that the customization is really easy, and intuitive.

    Setting up a facility to add a custom bunch of objects. I think there are already facilities to do this, but it’s really simple for standard cases and allows you to easily get things setup. You basically just need to override the Init method.

    protected override void Init()
    {</p>
    
    
    
    
    List<Assembly> assemblies = ReadConfigForAssemblies(FacilityConfig);
    <span class="kwrd">foreach</span> (Assembly assembly <span class="kwrd">in</span> assemblies)
        LoadCommands(assembly);
    

    }

    The configuration is already read in for you, so parsing that is easy.

    public List<Assembly> ReadConfigForAssemblies(IConfiguration facilityConfig)
    {
        List<Assembly> assemblies = new List<Assembly>();
        try
        {
            foreach (IConfiguration configuration in facilityConfig.Children)
                if (configuration.Name.Equals("assembly", StringComparison.InvariantCultureIgnoreCase))
                    assemblies.Add(Assembly.Load(configuration.Value));
        }
        catch (Exception e)
        {
            throw new ConfigurationErrorsException(
                "Assembly could not be loaded, check you have the correct name in the configuration.", e);
        }
        return assemblies;
    }

    Lastly, you can search through the configured assemblies and register any types that match what your looking for.

    private void LoadCommands(Assembly assembly)
    {
        foreach (Type type in assembly.GetTypes())
            if (typeof (IMyInterface).IsAssignableFrom(type) && !type.IsAbstract && type.IsPublic)
                Kernel.AddComponent(type.FullName, type);
    }

    This is getting to be a long post, but I'm sure you're wondering about testing. It's easy too! You have to mock out the configuration stuff, but that's really it. I just put into a setup method and once done you have your container setup and ready for testing.

    [SetUp]
    public void Setup()
    {
        _container = new WindsorContainer();
        _facility = new CommandFacility();
    
        _mocks = new MockRepository();
        IConfiguration config = mocks.DynamicMock<IConfiguration>();
        IConfiguration configChild1 = mocks.DynamicMock<IConfiguration>();
        IConfiguration configChild2 = mocks.DynamicMock<IConfiguration>();
    
        using (_mocks.Record())
        {
            Expect.Call(config.Children).Return(new ConfigurationCollection(new IConfiguration[] { configChild1 }));
            Expect.Call(configChild1.Name).Return("assembly");
            Expect.Call(configChild1.Value).Return("MyAssemblyName");
        }
    
        using (_mocks.Playback())
        {
            _facility.Init(_container.Kernel, config);
        }
    }

    There's more documentation on the Castle site. Next time custom dependency resolvers and sub kernels...