Actually the System.Reflection namespace is just not for this single
purpose, and may not even be the most appropriate solution in this case. If
you use reflection to load an assembly, you're restricted with how you can
use types in that assembly. You either have to use polymorphism or late
binding to do anything with them,.
The AppDomain.AssemblyResolve event might be a better solution here. This
enables you to decide at runtime where to load the assembly from, but it
doesn't require you to use reflection to access what is in those assemblies.
This means that when you build the project you can have the relevant
assembly as a reference in the usual way, it just gives you the flexibility
to decide where it will be loaded from at runtime.
However, there are a couple of issues with AssemblyResolve. (Or rather,
these are issues intrinsic to trying to decide at runtime where to load your
assemblies from, so any solution is likely to suffer from these problems -
it's usually better to avoid trying to do this in the first place.) I'd
read these articles before proceeding:
http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx
http://blogs.msdn.com/junfeng/archive/2004/04/25/119589.aspx
In particular read the comments - there's useful followup discussion.
