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.

Improve this question

5 Answers 5

Reset to default
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.

Improve this answer
6
  • 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 5, 2011 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 5, 2011 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 stackoverflow.com/questions/517058/…
    – Yam Marcovic
    Oct 5, 2011 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 5, 2011 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 5, 2011 at 16:05
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

Improve this answer
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

Improve this answer
1
  • +1 this seems to be the right answer, didn't how about the "extern" alias.
    – Jalayn
    Oct 5, 2011 at 12:44
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 ?

Improve this answer
4
  • 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 5, 2011 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 5, 2011 at 12:18
  • What is meant by GAC here?
    – Shamim Hafiz - MSFT
    Oct 5, 2011 at 19:44
  • 1
    Global Assembly Cache, see msdn.microsoft.com/en-us/library/yf1d93sz%28v=vs.71%29.aspx
    – Jalayn
    Oct 5, 2011 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).

Improve this answer
1
  • 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, 2015 at 6:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.