10

Though I have a specific case, but I was wondering about the general situation.

Can two DLLs, when added as Reference to a Visual C# project collide with each other to prevent the solution from building? If this is the case, what are the possible ways to mitigate this.

Scott C Wilson
  • 3,958
Shamim Hafiz - MSFT
  • 4,155

5 Answers5

16

This is very possible.

If you have defined an identical namespace and type name on different assemblies (or in your project and the added assembly), you will get a conflict with any code that tries to use one or another of these types.

If you ensure you have unique namespaces, as do your references you wouldn't have this problem.

Another possibility has to do with different versions of a dependency - if your project uses (for example) a logging library at version 1.2, but the added assembly has a dependency on the same assembly but a different version (say 1.3) and either your project or the added assembly has been configures/built to use a specific version, you will get a conflict and the build will fail.

Both these issues can be resolved using assembly aliases, as described here.

Community
  • 1
Oded
  • 53,734
5

Seeing as nobody else mentioned this, you asked:

what are the possible ways to mitigate this

There is a clean solution just for this case, without constraints, and without annoying workarounds. You can define Assembly alises so that the compiler would know which ones to refer to in the right place.

Have a look at Link

Glorfindel
  • 3,167
Yam Marcovic
  • 9,390
3

Yes, this is very possible.
Let's say you added a reference to some DLL which uses the old version of Lucene.Net and you want to include the latest version.
You could solve that problem by using extern aliases: http://msdn.microsoft.com/en-us/library/ms173212.aspx

šljaker
  • 476
1

You can put as many different versions of an assembly as you want in the Global Assembly Cache provided that they are strong-named. This may help you if you want different applications to use different versions of an assembly, machine-wise. However using different versions of an assembly in ONE application will still get you in trouble.

What is the reason for you to need both versions at the same time ?

Jalayn
  • 9,827
0

For sure. You can get the "Ambiguous Reference" compiler error, when two objects cannot be distinguished. Typically, you can specify the full path in code and it will not cause an issue, but if the dlls were fully identical, then you would not be able to distinguish between two object in any way. Sya we have two dlls:

System.IO which contains the File class

and

MyProject.IO which contains a File class

If you were to have something like this...

using System.IO;
using MyProject.IO;

...
private void foo()
{
    File f = new File();
}

... you would have an ambiguous reference, since there is no way to tell which file you are talking about. This would fix it:

using System.IO;
using MyProject.IO;

...
private void foo()
{
    MyProject.IO.File f = new MyProject.IO.File();
}

The only way it would be difficult to fix would be if "File"'s path was identical in both assemblies, but that would require the unlikely situation where two dlls had an identical namespace structure. For example, my situation above would never happen, since no one is going to name there project "System" (with the exception of the actual developers of the .Net framework).