Embora eu tenha um caso específico, mas estava pensando sobre a situação geral.
Duas DLLs, quando adicionadas como referência a um projeto do Visual C #, podem colidir entre si para impedir a criação da solução? Se for esse o caso, quais são as formas possíveis de atenuar isso.
Respostas:
Isto é muito possível.
Se você definiu um namespace idêntico e digite o nome em diferentes assemblies (ou no seu projeto e no assembly adicionado), você entrará em conflito com qualquer código que tente usar um ou outro desses tipos.
Se você garantir que possui namespaces exclusivos, assim como suas referências, não terá esse problema.
Outra possibilidade tem a ver com versões diferentes de uma dependência - se o seu projeto usar (por exemplo) uma biblioteca de log na versão 1.2, mas o assembly adicionado tiver uma dependência do mesmo assembly, mas uma versão diferente (por exemplo, 1.3) e seu projeto ou o conjunto adicionado foi configurado / construído para usar uma versão específica, você terá um conflito e a construção falhará.
Esses dois problemas podem ser resolvidos usando aliases de montagem, conforme descrito aqui .
Como ninguém mais mencionou isso, você perguntou:
quais são as possíveis maneiras de mitigar isso
Existe uma solução limpa apenas para este caso, sem restrições e sem soluções irritantes. Você pode definir alises de montagem para que o compilador saiba a quem se referir no lugar certo.
Dê uma olhada em http://blogs.msdn.com/b/ansonh/archive/2006/09/27/774692.aspx
Sim, isso é muito possível.
Digamos que você adicionou uma referência a alguma DLL que usa a versão antiga do Lucene.Net e deseja incluir a versão mais recente.
Você pode resolver esse problema usando aliases externos: http://msdn.microsoft.com/en-us/library/ms173212.aspx
Você pode colocar quantas versões diferentes de uma montagem quiser no Cache de Montagem Global, desde que elas tenham nome forte. Isso pode ajudá-lo se você quiser que aplicativos diferentes usem versões diferentes de uma montagem, em termos de máquina. No entanto, o uso de versões diferentes de uma montagem em UM aplicativo ainda causará problemas.
Por que você precisa das duas versões ao mesmo tempo?
Com certeza. Você pode obter o erro do compilador "Referência ambígua" quando dois objetos não podem ser distinguidos. Normalmente, você pode especificar o caminho completo no código e isso não causará um problema, mas se as dlls forem totalmente idênticas, não será possível distinguir de maneira alguma dois objetos. Sya, temos duas DLLs:
System.IO que contém a classe File
e
MyProject.IO que contém uma classe File
Se você tivesse algo assim ...
using System.IO;
using MyProject.IO;
...
private void foo()
{
File f = new File();
}... você teria uma referência ambígua, pois não há como saber de qual arquivo você está falando. Isso o corrigia:
using System.IO;
using MyProject.IO;
...
private void foo()
{
MyProject.IO.File f = new MyProject.IO.File();
}A única maneira de corrigir isso seria se o caminho do "Arquivo" fosse idêntico nos dois assemblies, mas isso exigiria a situação improvável em que duas DLLs tinham uma estrutura de namespace idêntica. Por exemplo, minha situação acima nunca aconteceria, pois ninguém nomeará o projeto "Sistema" (com exceção dos desenvolvedores reais da estrutura .Net).