Dependência persistente de assembly em C# .NET

Question

Meu projeto C# - vamos chamá-lo de SuperUI - usado para fazer uso de uma classe de um assembly externo.Agora isso não acontece, mas o compilador não me permite construir o projeto sem a referência de montagem no lugar.Deixe-me elaborar.

Este projeto costumava lançar e capturar uma classe de exceção personalizada - o SuperException - que foi derivado do System.Exception padrão e residia em um assembly pré-compilado separado, SuperAssembly.DLL, que mencionei.

Eventualmente, decidi que este era um exercício inútil e substituí todos SuperExceptions com um System.SuitableStandardException em cada caso.Eu removi a referência a SuperException.DLL, mas agora me deparei com o seguinte ao tentar compilar o projeto:

O tipo 'SuperException' é definido em um assembly que não é referenciado.Você deve adicionar uma referência ao assembly 'SuperException, Version=1.1.0.0 (...)'

O arquivo de origem referenciado pelo erro não parece relevante;é o namespace do projeto que é destacado no IDE.

Agora, aqui está a coisa:

1. Todos os usos de SuperException foram eliminados do código do projeto.
2. Comparado com outro projeto que compila bem sem uma referência a SuperException.DLL, faço referência apenas a mais um assembly - e that não faz referência a nada que meu projeto não faça referência a si mesmo.Embora seja possível que qualquer uma dessas dependências possa lançar SuperExceptions, estou apenas capturando a classe base Exception e em qualquer caso...o outro projeto funciona bem!
3. Eu fiz a "Solução Limpa" do Visual Studio e limpei tudo manualmente, muitas vezes.

Não é o fim do mundo incluir esta referência, só não vejo porque é que é mais necessária.Nrrgg.Qualquer indicação é bem-vinda!

Answer 1

É provavelmente uma referência transitiva, onde alguma chamada de método de tipo retorna uma instância de SuperException em caixa ("downcast") como, por exemplo.Exceção, mas da inspeção do código no código incluído transitivamente, ou seja,código de suas chamadas de método externo, o compilador sabe que você precisa ter informações sobre esse tipo em algum momento.

O Resharper diria onde é necessário adicionar uma referência, e você poderia usar o Refletor de Lütz Roeder, também conhecido como RedGate, para verificar o IL compilado em busca de uma referência a esse tipo de duas maneiras:1) use o recurso de pesquisa, 2) abra cada tipo público que você está usando e para aquele que requer a montagem "fantasma", ele solicitará que você especifique sua localização.

Isso acontece com mais frequência comigo quando faço referência a Castle.Windsor, mas não a Castle.MicroKernel.:p

Answer 2

1. Saia do Visual Studio
2. Exclua as pastas bin e obj em seu diretório de solução
3. Reinicie e veja o que acontece

Answer 3

Concordo com os outros comentários aqui..Há uma referência, em texto simples em algum lugar !Já tive problemas semelhantes no passado, em que a pesquisa nos arquivos do projeto não retornou nada, mas descobri que estava em algum outro arquivo que não foi selecionado automaticamente na pesquisa.

Não creio que criar um novo projeto seja a solução aqui.Você precisa ter certeza de que NENHUM das referências em sua árvore de dependências use SuperException. NENHUM

Nunca experimentei isso a ponto de precisar literalmente limpar o projeto, sempre encontrei a referência em algum lugar.Certifique-se de que você está pesquisando todo arquivo.

EDITAR:

Apenas um ponto a acrescentar: se o local apontado pelo erro parecer aleatório, isso muitas vezes pode significar que há uma incompatibilidade entre a fonte compilada e o arquivo de código-fonte.Este é um aplicativo ASP.NET?Eu já tive isso antes, onde as DLLs compiladas não foram substituídas em uma reconstrução na pasta temporária do ASP.NET, fazendo com que as coisas ficassem ..Interessante ao depurar :)

Answer 4

Não acho que seja um problema de código.O que posso ver acontecendo é que uma de suas referências existentes provavelmente depende desse tipo em seus próprios tipos que você provavelmente está criando em seu aplicativo.

Se for esse o caso, você precisa dessa referência, mesmo que não use explicitamente o tipo e mesmo que o outro assembly referenciado tenha sua própria referência.Às vezes você tem esse problema com componentes de terceiros que precisam de referências a tipos que você não referenciou.O compilador obviamente está vendo algo em um de seus assemblies referenciados existentes e espera que você faça referência ao dependente.

Answer 5

Como é um erro do compilador, deve haver uma referência ou uso de SuperException em algum lugar do projeto.

1. Faça uma localização/substituição em todo o projeto ou solução para esse tipo e remova todas as referências (é possível que você já tenha feito isso).
2. Se você fizer referência a qualquer tipo que herda de SuperException (mesmo que seja o tipo definido em outro assembly), será necessária uma referência ao assembly no qual SuperException está definido.

Pegue a linha em que o compilador está mostrando o erro e comece a rastrear a árvore de herança dos objetos usados ​​​​nessa linha, você pode encontrar a origem disso dessa forma.

Answer 6

Obrigado por suas respostas até agora.Tentei todas as sugestões (exceto uma) sem sucesso.

A sugestão que não tentei é criar um novo projeto e adicionar todas as minhas coisas a ele, cuja ideia realmente testa minha vontade de viver.;) Posso tentar isso amanhã se me incomodar.Obrigado novamente.

Answer 7

Não há realmente nada de muito misterioso nos projetos VS hoje em dia - são todos arquivos de texto, etc.ALGO deve fazer referência a essa classe/dll, e esse algo deve fazer parte do seu projeto.

Você realmente encontrou ou encontrou toda a árvore de soluções, cada arquivo, para uma referência a essa exceção?

Answer 8

Isso parece muito estranho.Aqui está o que eu verificaria a seguir:

1. Verifique se não há nada remanescente em seu arquivo Properties/AssemblyInfo.cs.
2. Verifique se não há nada remanescente no arquivo SuperUI.csproj.
3. Exclua todas as referências e adicione-as novamente.

Answer 9

Tente criar um novo projeto e adicionar todas as suas classes a ele.

Answer 10

grep a pasta do seu projeto.Pode ser uma referência oculta no seu projeto ou um projeto referenciado pelo seu projeto.Limpe com o bloco de notas, se necessário.

Answer 11

Se você fizer referência a qualquer tipo que herda de SuperException (mesmo que seja o tipo definido em outro assembly), será necessária uma referência ao assembly no qual SuperException está definido.

Apoiado nisso.

Você pode não estar fazendo referência SuperException, mas você pode estar se referindo SpecializedSuperException, que é derivado ou de alguma forma usa SuperException - seu grep do projeto para SuperException não vou pegar isso.

Tente fazer um hack com o teste de NDepend

Answer 12

É aqui que ferramentas como Reafiador realmente vale a pena - um simples Find Usages geralmente me informa sobre essas "dependências fantasmas" várias vezes.

Talvez você possa ir para a sua definição da classe SuperException e tentar Find All References().Você também pode querer investigar se o assembly SuperException tem um dependência circular na sua montagem principal (por exemplo, a montagem principal depende da montagem de exceção depende da montagem principal...).

Answer 13

Eu tive um problema de referência de assembly muito semelhante que estava acontecendo quando minha biblioteca C# tinha um assembly C++/CLI dependente.O problema foi que eu estava herdando uma classe pública daquele assembly C++/CLI em minha biblioteca de assembly C#.Isso significava que a cadeia de herança se estendia por vários assemblies.

Eu esperava que qualquer cliente fosse inteligente o suficiente para carregar indiretamente o assembly C++/CLI sempre que a biblioteca C# precisasse, mas esse não foi o caso, mesmo em tempo de compilação.

Eu me livrei desse problema quebrando a herança entre as classes que se estendiam por essas duas bibliotecas assembly e usando agregação.Meu cliente finalmente ficou satisfeito e não precisava mais do assembly C++/CLI como dependência.

Em sua palavra, você provavelmente teria que ter certeza de que SuitableStandardException não herda de SuperException para eliminar o SuperException.DLL como referência.

Use encapsulamento em vez de herança e crie um SuperException membro de dados em seu novo SuitableStandardException.

Se isso não resolver o problema, você poderá ter mais classes abrangendo herança em alguns assemblies, no seu caso SuperAssembly.DLL e superException.dll.

Se você não conseguir encontrar todos eles, tente este truque:

1. Faça com que todos os seus membros públicos e classes SuperAssembly.DLL interno.

2. No SuperAssembly.DLL faça amizade com SuperException.DLL:

   [assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]
   

3. Certifique-se de que eles construam e removam o SuperAssembly.DLL referência de qualquer cliente que já faça referência SuperException.DLL.

Answer 14

grep -R SuperException * na base do seu projeto (obtenha grep de algum lugar primeiro) só para ter certeza.