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,908
  • 20
  • 25
Shamim Hafiz - MSFT
  • 4,123
  • 7
  • 38
  • 46

5 Answers5

15

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,326
  • 19
  • 166
  • 181
  • I'm not entirely sure this is true. If you look at the CIL, the CLR refers to symbols explicitly within certain assemblies with the [assembly] notation before each symbol. It's possible that the C# compiler enforces this issue, but I don't think it's a platform constraint. – Yam Marcovic Oct 05 '11 at 12:33
  • @Yam Marcovic how would the complier figure out which namespace you are trying to use in a particular class? Fully-qualified class name conflicts are definitely going to prevent a build. – Jeremy Oct 05 '11 at 14:50
  • The C# compiler provides you with an option for assembly aliases, when dealing with assemblies of the same name (and possibly having same symbols defined in them). See http://stackoverflow.com/questions/517058/how-to-reference-a-namespace-from-a-specific-assembly – Yam Marcovic Oct 05 '11 at 15:23
  • @Yam - True, however, you need to know about this flag and use it. Simply adding the assembly would break the build. – Oded Oct 05 '11 at 15:25
  • 1
    Obviously. That's why he comes here for help, though, right? He wants to know about this flag and use it, because it will give him a cleaner solution, without affecting his project or 3rd party utilities. – Yam Marcovic Oct 05 '11 at 16:05
  • In my case, I added the alias name in the .csproj https://stackoverflow.com/questions/32201437/dapper-ambiguous-extension-methods/55620553#55620553 – Mayer Spitz Apr 10 '19 at 20:47
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,137
  • 6
  • 25
  • 33
Yam Marcovic
  • 9,270
  • 2
  • 27
  • 29
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
  • 3
  • 10
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,789
  • 4
  • 39
  • 58
  • 1
    Well I am not explicitly adding different versions. Basically I have a WPF app. Now, in order to add a third party feature, I have added some DLLs and it's these DLLs that are maybe in conflict. – Shamim Hafiz - MSFT Oct 05 '11 at 11:56
  • 1
    OK, then you may perhaps add these third party related DLLs to the GAC ? It's been a long time since I read about those things but I suspect this could solve your problem. – Jalayn Oct 05 '11 at 12:18
  • What is meant by GAC here? – Shamim Hafiz - MSFT Oct 05 '11 at 19:44
  • 1
    Global Assembly Cache, see http://msdn.microsoft.com/en-us/library/yf1d93sz%28v=vs.71%29.aspx – Jalayn Oct 05 '11 at 20:09
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).

Morgan Herlocker
  • 12,722
  • 8
  • 47
  • 78
  • Actually it happens a lot, if you build solutions based on popular third party libraries. For example, a twitter libraries may depends on an older version of your json lib – Hoàng Long Dec 17 '15 at 06:48