2

Under what conditions can I swap out an assembly that's statically referenced at compile time with a different one for use at runtime? For example:

App Assembly:

  • References Common Assembly
  • References ServiceProviderFactory in Service Assembly

Common Assembly:

  • Defines IServiceProvider

Service Assembly:

  • Provides ServiceProviderFactory (a factory for IServiceProviders)
  • References Common Assembly

Given the above, I'd like to be able to swap out the Service assembly at install time but I don't know under what conditions the new Service assembly will continue to load.

I believe the following must hold:

  1. Same assembly name,
  2. Weakly named assembly or same version number in a strongly named assembly, and
  3. ServiceProviderFactory signature remains constant.

Note: it seems better to use reflection and search the service assembly for an implementation of IServiceProvider than to rely on some ServiceProviderFactory with a fixed signature being present but I'm still interested in the answer to the above.

Brian Knoblauch
  • 20,639
  • 15
  • 57
  • 92
Kaleb Pederson
  • 45,767
  • 19
  • 102
  • 147

1 Answers1

1

If it's strong-named, then you can't really use assembly redirection for anything other than version differences. However, you can use the AppDomain.AssemblyResolve event to supply an assembly in response to a failure to bind the requested assembly.

I actually tried this as a proof of concept when I tried to support .NET 2.0 assemblies that referenced a CodePlex build of MEF in a .NET 4 application that referenced the released build of MEF. Here's a link to my question that someone responded to with that evil trick.

However, this is all very tricky and I wouldn't feel comfortable doing it in a real application. Can you extract your interfaces into a separate assembly then use some kind of dependency injection such as MEF or Unity to dynamically load the types that implement those interfaces?

Community
  • 1
  • 1
Josh
  • 68,005
  • 14
  • 144
  • 156
  • I hadn't considered DI for dynamically loaded assemblies, but that's a very good idea. I imagine that any DI container could handle that as long as the assembly was loaded before the binding was created. If the DI container had hooks into assembly loading it could check the assembly for mappings defined by the dynamically loaded assembly then I wouldn't need to reference an implementation class defined within the assembly, which would be optimal. – Kaleb Pederson Dec 10 '10 at 16:09