2

I have a rather unusual problem and need some ideas.

I maintain two codebases that are 99% identical. A new project has come along that under some runtime condition needs to use code base A and in other conditions use precompiled code base B.

I have abstracted the functionality into an interface for the project and plan to have two implementation assemblies that reference the different code bases. I plan on using a service locator pattern to instantiate the object. So it looks a little like this.

Assembly A (Website)              Assembly B           Libraries
-------------------------------|--------------------|-------------
    Project -> Service Locator -> Implementation A -> Code Base A
                               -> Implementation B -> Code Base B

My concerns lie around in loading the same named assemblies of code base a and b and having runtime conflicts.

What is the best approach for this scenario and why?

starblue
  • 55,348
  • 14
  • 97
  • 151
Slappy
  • 4,042
  • 2
  • 29
  • 41
  • If they are different, then they shouldn't have the same name or version. Why don't you extract only those things that vary into two different libraries? If it's only 1% each library shouldn't be very big. – Mark Seemann Sep 28 '11 at 11:00
  • Lets assume (quite correctly) that this isn't an option and the code base is a massive mess of years worth of legacy spaghetti code, they are out of my control. Assume the code bases are gelatinous blobs. Oh also, they are identically named, which is what makes this an interesting problem. – Slappy Sep 28 '11 at 23:51

1 Answers1

2

It sounds to me that if you give each assembly a different name it would effectively solve the problem. Even though the code base in each assembly would be nearly identical, assemblies are identified by name (and other characteristics), so naming them differently would ensure that they don't collide. The types (classes etc.) inside each assembly use the assembly name to build their fully qualified names, so you shouldn't have any conflicts there.

However, the interface behind which you hide the assembly types must be defined in a third library (which might be your consuming library).

Mark Seemann
  • 225,310
  • 48
  • 427
  • 736
  • Yes, I understand this. Which is why I posed the question. But sadly as mentioned I cannot make any changes to the code bases, so I need a way to load them (hopefully via a neat tool) into their own appdomains, etc (and unload as needed). I was hoping that some IoC framework had the answer to this. – Slappy Sep 29 '11 at 05:07
  • Not that I'm aware of, no. DI Containers can't break the rules of the runtime. However, if the types you interact with are either serializable or derive from MarshalByRefObject, you can load each library into its own AppDomain, but that sounds more like a job for the System.AddIns API. – Mark Seemann Sep 30 '11 at 05:59