Skip to main content

CastleWindsor issue with MVC Area

I have been stuck with this issue and couldn't take it out of my head. Hence, ended up putting in some heavy hours solving it. But hopefully it is worth it.

THE CONTEXT:

I am implementing a MVC solution for an existing Sitecore 8.0 implementation which uses Castle Windsor for it's dependency resolver. Let's say a a tiny microsite. I had to implement a SPEAK app as per one of the requirements. Below are the 2 most important things behind why I ran into this issue in the first place:

I needed to call a WebApi from my SPEAK app.
2. I decided to take MVC Area approach for my "tiny microsite" on a completely different sets of dlls

For example the dlls for my "tiny microsite" are MyTinyApp.Web.dll, MyTinyApp.Business.dll whereas the main website's dlls are BigWebsite.Web.dll, BigWebsite.Business.dll etc. 


WHY MVC AREA:

The reason I took the MVC Area approach was to completely separate my "tiny microsite" so that I don't have to touch any of the code from "BigWebsite" implementation (Or it can also be that the code base for the "Big Website" was unavailable to me .. imagine whatever floats your boat).


THE PROBLEM:

After I implemented my MVC Area project on dll called "MyTinyApp.Web.dll" for my "tiny microsite) upon trying to call the WebApi I started getting bellow error:



From the error it's clear that the routing got resolved without any issue. But Castle Windsor for some weird reason decided to step in like "hai .. new controller .. i need to resolve this" which I would be cool with until it couldn't and threw the bizarre error that doen't make sense to begin with. 

I have never told Castle Windsor to resolve any of my stuff for "MyTinyApp.Web.dll" and the exception was getting thrown from BigWebsite.Web.dll. 

WEIRD.


THE SOLUTION:

1. Create a processor in one of your project specific config file like below:


<pipelines>
      <initialize>
                               <processor patch:before="processor[@type='Sitecore.Mvc.Pipelines.Loader.InitializeGlobalFilters, Sitecore.Mvc']" type="MyTinyApp.CastleWindsor.Pipelines.Initialize.InitializeWindsorControllerFactory, MyTinyApp.CastleWindsor" />
     </initialize>

 </pipelines>

2. Create a settings to get the assembly name associated with Big Website's dependency resolver.

  <setting name="BigWebsiteDependancyResolverAssembly" value="BigWebsite.Web.DependencyResolution.ContainerManager,BigWebsite.Web" />

3. Implement the ControllerFactory for TinyApp:


public class InitializeWindsorControllerFactory
    {
        public virtual void Process(PipelineArgs args)
        {
            string assemblyAndClass = ConfigHelper.GetValue("BigWebsiteDependancyResolverAssembly");
                Type resolverType = Type.GetType(assemblyAndClass);
                IWindsorContainer icontainer = (IWindsorContainer)(resolverType.GetProperty("Container").GetValue(null));

                icontainer.Register(Classes.FromAssemblyNamed("oblog.client.mvc").BasedOn<IController>().LifestyleTransient());
        }

    }

And waalaaa .. Double Rainbow and Unicorn,



The trick here was to get it through reflection.

Thus I do not have to touch the BigWebsite codebase at all so I can avoid deployment headache for it. Resolving though reflection makes it completely independent to any other dlls.  

"This is mainly intended for future me." but seriously CastleWindsor WTF !!!!



UPDATE:



So one of my genius colleagues figured out that original implementation of ControllerFactory in BigWebsite.Web project(csproj) had flaw in it. 

Here's his post:


So it was originally like below:

public class WindsorControllerFactory : DefaultControllerFactory
    {
        private readonly IKernel kernel;

        public WindsorControllerFactory(IKernel kernel)
        {
            this.kernel = kernel;
        }

        public override void ReleaseController(IController controller)
        {
            kernel.ReleaseComponent(controller);
        }

        protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
        {
            if (controllerType == null)
            {
                throw new HttpException(404, string.Format("The controller for path '{0}' could not be found.", requestContext.HttpContext.Request.Path));
            }

            return (IController)kernel.Resolve(controllerType);
        }

    }

Because of this line in the implementation of the ContainerManager class which you put in the initialize pipeline:
container.Install(FromAssembly.InDirectory(new AssemblyFilter(Path.GetDirectoryName(Uri.UnescapeDataString((new UriBuilder(Assembly.GetExecutingAssembly().CodeBase)).Path)), "BigWebsite*.dll")));
the described error was getting thrown from this line :  
return (IController)kernel.Resolve(controllerType);

Weirdly, most of the blog/tutorials show this example for implementing Castle Windsor for MVC.
The fix is to have this instead:
try
            {
                return (IController)kernel.Resolve(controllerType);
            }
            catch (Exception ex)
            {
                // do something
                return base.GetControllerInstance(requestContext, controllerType);

            }

And everything else works fine from here. No need to implement extra pipeline to inject you "mvc area" implementation dll into the pipeline or modify existing implementation.


Hope it helps someone facing the same issue save time so that he/she can utilize it properly to dress up like wookie.

  



Comments

Popular posts from this blog

Reimagining Logs: Building AI powered Conversational Observability System

It is mid-2025 and the cogs of AI are at full speed. So we (I and Mobin) decided to do our own AI project. We called it "IntelliLogs".  IntelliLogs at a glance: Demo:  https://www.youtube.com/watch?v=OXMlORwyMQk In this post I will describe why we did what we did, what is it that we did and how we did it. I will share my personal experience. I am hoping this will, at least, be an interesting read. Table of contents: Why IntelliLogs What is IntelliLogs How IntelliLogs was developed Future of IntelliLogs Conclusion References Why IntelliLogs: Personal motivation ðŸ’ª to this were: Explore and experience what does an AI app look like from an architectural and engineering perspective Explore the realm of Huge LLMs (eg: GPT-4.1-170B,  Gemini Pro etc) vs small LLMs (eg: granite-7b, gemma-4b) Explore the possibilities of model tuning / making a model without being a data scientist. How easy or hard it is, what tools available etc. We also wanted to tackle a "not too far from ...

The story of a Hack Job

"So, you have hacked it" -- Few days ago one of the guys at work passed me this comment on a random discussion about something I built. I paused for a moment and pondered: Do I reply defending how that's not a hack. OR Do I just not bother I picked the second option for 2 reasons: It was late. It probably isn't worth defending the "hack vs" topic as the comment passed was out of context. So I chose the next best action and replied "Yep, sure did and it is working great.". I felt like Batman in the moment. In this post I will rant about the knowledge gap around hacking and then describe about one of the components of my home automation project (really, this is the main reason for this post) and use that as an example how hacking is cool and does not always mean bad. But first lets align on my definition of hacking: People use this term in good and bad, both ways. For example: "He/she did a hack job" -- Yeah, that probably...

Understanding The Ingress and The Mesh components of Service Mesh

I wrote about the key concepts about service mesh and how to evaluate the requirements for a service mesh in my previous post here:  Deciphering the hype of Service Mesh . This post is a follow up from there covering the technical aspects. Part 1:   Deciphering the hype of Service Mesh Part 2:   Understanding The Ingress and The Mesh components of Service Mesh. Part 3: Uderstanding the observability component of Service Mesh (TBD in another post).  Almost all popular service mesh technologies/tools (eg: Istio, LinkerD) have both ingress and mesh capabilities. Conceptually, I see them as 2 mutually exclusive domain (integrated nicely by the underlying tool). Understanding  the ingress  and  the mesh  components individually, such as what they offer, what I can do with them etc, was the basic building block to my understanding of service mesh technology as a whole. This is arguably the most mis-represented topic in the internet. So, I thought,...

CKA Exam; May 2024: My take on it and cheat sheet

So, I finally got the little green tick of having CKA certification in my certification list. I put off this exam for so long that it seriously became not funny anymore. The internet has quite literally way more than 1000 posts on this topic. But what harm would one more post cause? So here's mine. I will write it from my perspective. I am writing this post just in case if anyone benefits from it, as I predict there could be many on the same boat as me. Background: Kubernetes, modern application architecture, DevSecOps etc are not new territory for me. In fact, I think I am fairly versed in K8s and related tech stack. But due my own imposter syndrome I have been putting off sitting the CKA exam. However, last week I thought about the CKA as "just another approval for my skills" and got the nudge to sit the exam.  Here's what I did till the day I sat for the exam. (Everybody is different but the below worked for me the best) The preparation: As I have been working with...

Openshift-Powered Homelab | Why, What, How

I wanted to build a Homelab for some time but it was taking a backseat as I always had access to cloud environments (eg: cloud accounts, VMware DC etc) and the use cases I was focusing on didn't really warrant for one. But lately, some new developments and opportunities in the industry triggered the need to explore use cases in a bare-metal server environment, ultimately leading to the built of my own homelab, called MetalSNO. In this post, I will discuss some of my key reasons for building a homelab, the goals I set for it, and the process I followed to building one from scratch. I'll conclude with some reflections on whether it was truly worth it and what I plan to do with it going forward. Compelling reasons (The Why ) My uses cases for a homelab weren't about hosting plex server, home automation etc (I have them on Raspberry PIs for some years now). My Homelab is really about exploring technologies and concepts that are on par with industry trend. Below are some of the ...

Smart wifi controlled irrigation system using Sonoff and Home Assistant on Raspberry Pi - Part 1

If you have a backyard just for the sake of having one or it came with the house and you hate watering your garden or lawn/backyard then you have come to the right place. I genuinely believe that it is a waste of my valuable time. I would rather watch bachelorette on TV than go outside, turn on tap, hold garden hose in hand to water. Too much work!! Luckily, we have things like sprinkler system, soaker etc which makes things a bit easy. But you still have to get off that comfy couch and turn on tap (then turn off if there's no tap timer in place). ** Skip to the youtube video part if reading is not your thing   When I first moved into my house at first it was exciting to get a backyard (decent size), but soon that turned on annoyance when it came down maintaining it, specially the watering part. I laid bunch sprinklers and soaker through out the yard and bought tap timer but I still needed to routinely turn on the tap timer. Eventually few days ago I had enough of this rub...