4
votes

I'm currently maintaining some old code for a company. As it would happen, the current app I'm modifying uses an older version of the in-house library (we'll call this Lib1.dll). They also have a new version of the library called Lib2.dll that improves upon the previous library in many ways.

Unfortunately, Lib2 is not backward compatible with Lib1. What's worse is that they both use the same namespace Product.Common.

How do I use Lib2 and Lib1 in the same project? Right now if I add references to both of them, VS tells me that certain classes are ambiguous (which makes sense, since they using the same namespace).

Basically, I need something like:

Imports Lib1:Product.Common.Class

I'm using VB.NET 1.1.

4
I ran into this same problem in C#, I'm interested if there are any ways around this - Andy White
@Andy: The C# solution is easy, not sure about VB.NET. - Samuel
That's not a solution though... these two libraries have the exact same namespace. You can use the namespace to differentiate them. The only thing that is different is that they have different DLL names. - cdmckay
@cdmckay: Aaah, I see it now. Found a C# answer and will post. - Samuel
@cdmckay: You might be SOL. Haven't found any solutions that don't use extern alias. - Samuel

4 Answers

6
votes

I found a blog entry that has a solution in C#, not sure of the solution in VB.NET.

Extern alias walkthrough and C# 2.0: Using different versions of the same dll in one application


Edit:

It would seem you are out of luck. There does not appear to be a solution with .NET 1.1.

5
votes

You could add another project to "host" one of your Lib projects. Basically just add a layer to nest the namespace a level deeper so it no longer causes a conflict.

1
votes

If Lib2.dll improves over Lib1.dll, why do you still need Lib1.dll? The best thing to do is remove Lib1.dll from your project and just use Lib2.dll.

if not, try this link and see if that helps

http://blogs.msdn.com/ansonh/archive/2006/09/27/774692.aspx

1
votes

I think Joel's answer is probably the easiest approach. But another more extreme option would be to run the program through ildasm, do a search replace on the namespace, and run the result through ilasm.

You could run into other issues, such as signing, with this approach, but it would allow you to "rename" the namespace in the assembly.