Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

5 Answers 5

up vote 8 down vote accepted

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.

share|improve this answer
    
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 '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 5 '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 stackoverflow.com/questions/517058/… –  Yam Marcovic Oct 5 '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 5 '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 5 '11 at 16:05
add comment

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 http://blogs.msdn.com/b/ansonh/archive/2006/09/27/774692.aspx

share|improve this answer
add comment

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 ?

share|improve this answer
    
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 Oct 5 '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 5 '11 at 12:18
    
What is meant by GAC here? –  Shamim Hafiz Oct 5 '11 at 19:44
1  
Global Assembly Cache, see msdn.microsoft.com/en-us/library/yf1d93sz%28v=vs.71%29.aspx –  Jalayn Oct 5 '11 at 20:09
add comment

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

share|improve this answer
    
+1 this seems to be the right answer, didn't how about the "extern" alias. –  Jalayn Oct 5 '11 at 12:44
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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