views:

50

answers:

3

I'm working with dependency injection (DI from now on) to resolve components and am looking for an elegant solution to loading dependent assemblies in a .NET environment. As an explanation, lets say that we have 3 assemblies, A, B and C, where A depends on B and B depends on C. Now I need to load components from assembly A, but because I am using DI, I don't have a reference to assembly A. And even a reference to assembly A wouldn't be enough because I somehow need to ensure that A, B and C all end up in my output directory.

So, some obvious solutions are to:
- add references to A, B and C from the executing application: Requires knowledge of the dependency structure which, in my case, is extremely complex, making this a somewhat undesired solution.
- add these dlls to the GAC: Just not an option in my case.


So I'm wondering if anyone has an elegant solution to this issue. Not sure if it's relevant but I'm using Castle Windsor for DI.

Thanks
Joni

+4  A: 

There is an event called AssemblyResolve on your AppDomain that gives you a chance to load missing assemblies. This lets you load your missing assembly from any stream you provide such as a file in a different folder or a file stored in a database.

David
This might be the best option I've seen so far. Thanks.
joniba
+1  A: 

What would it buy you to load the assemblies dynamically?

You should just add references to A, B, and C in the executing application, unless you're writing an application designed to be extended by other parties, or you have to change the dependencies extremely frequently.

Otherwise, you're solving a trivial problem (the need to recompile to deploy changes) by introducing a different problem (the possibility of failing at runtime).

Think of the list of references as your application's constructor arguments - your application should clearly declare its dependencies instead of tucking them away in a config file.

Jeff Sternal
Essentially I agree with you. I'm just looking for other options that people have employed to deal with this issue. In my case, in particular, a lot of knowledge is required to know which dependencies need to be added to the employing projects, because the dependency structure is very complex. I've updated the post to reflect that.
joniba
+1  A: 

If the only issue you have is getting the assemblies in the output directory than it's not a Windsor question - it's a MsBuild question (or NAnt or whatever you're using to build your project). Just have your script do it.

If you're looking at extensibility scenario, that is you have the assemblies in the directory and you want to load them, Windsor 2.5 (current trunk) has some pretty nice support for this as well, both from XML and from fluent API.

Krzysztof Koźmic