VB.net usage for multiple dlls of same namespace

We need a solution for the following concept in vb.net,
DLL A and DLL B has same Namespace but different versions
DLL C and DLL D has same Namespace but different versions
wherein the same vb.net application has to use DLL A in one form and DLL B in another form, where DLL A calls DLL C internally and DLL B calls DLL D internally, how to achieve this for DLL reference and at run time. Both the forms can be run at the same time so which dll shall be used by the assembly.
Who is Participating?
abelConnect With a Mentor Commented:
4 questions asked, 3 questions open: consider cleaning up your abandoned questions. You can read up on this here: http://www.experts-exchange.com/help.jsp?hi=462

On topic: it is also possible to do this (if you really really must) with the assemblyBinding and qualifyAssembly directives inside the app.config or web.config. You can use it to give an alias for a fully qualified name (fully qualified means: including version). In addition, you can use bindingRedirect to forward a certain version of an assembly.

Finally, if it is about functionality that has moved from one DLL to another but you do not want or cannot recompile existing applications, you can use the TypeForwardedToAttribute.

But, like I said earlier and as Dhaest confirms: if you can, avoid this nightmare.

-- Abel --
Sounds like a nightmare scenario to me... I don't have an answer for you, but I can point you perhaps in the right direction:

The easiest way you can do this is to wrap the dlls in a proxy class. The proxy class then should take care of the loading of the DLL. A wrapper, then, which should be version-agnostic, can take care of "being" the interface to either DLL. The calling application (or other DLLs, will have no notion of what version it is.

But, instead of going that path, it is best to design your product in such a way that you version all your components alike to prevent this disaster scenario.

-- Abel --
The namespaces is just done to make sure that you don't get into such a horrible scenario ...

Why don't you create one dll containing all the functions of both DLL's ?
You can easily create different classes in the same dll !
This question was actually well answered, I don't think deletion is in place. My suggestion would be to accept the following comment as solution, because it explains exactly (after the rant) how you can tackle this issue:

suggestion to accept http:#24665806 as answer.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.