Como depurar uma dll referenciada (com pdb)


132

Eu tenho duas soluções no meu espaço de trabalho, digamos A e B.

A solução A é um projeto mais antigo que terminei de codificar há algum tempo. Na solução B, preciso usar algumas classes da solução A. Para fazer isso, adiciono uma referência à dll de um dos projetos na solução A.

O problema é quando tento depurar. Quero poder entrar no código de A também. O Visual Studio não pode carregar o código para essas classes ("Não há código fonte disponível para o local atual.") E só posso ver a desmontagem, o que não é útil.

A única maneira que conheço para depurar classes da solução A é executando a solução B, desanexe todos os processos (no item de menu Debug) e anexe o processo da solução A.

No entanto, isso é muito inconveniente e só posso depurar A ou B de uma vez.

Existe uma maneira de permitir entrar no código de dlls referenciadas (para as quais eu tenho o código-fonte)?


Solução: Meu erro foi pensar que um projeto só pode fazer parte de uma única solução. De fato, um projeto pode fazer parte de qualquer número de soluções.
Quando precisar fazer referência ao projeto antigo, basta adicionar o projeto à solução. Isso é feito clicando com o botão direito do mouse na nova solução em Solution Explorer> Add> Existing Project.
Em seguida, você poderá adicionar a referência do projeto. Como outros escreveram, você provavelmente deve evitar completamente o uso de referências de DLL ao seu próprio código (ou outro código que você precise alterar e depurar).

Uma referência muito boa sobre como as soluções devem ser projetadas pode ser encontrada no MSDN .


Esse link do MSDN é uma leitura obrigatória para os desenvolvedores .net (independentemente do controle de origem que eles usam). Estou surpreso por não ter visto isso antes. Obrigado!
Pat

Recém-chegados, se você já conhece as referências do projeto, e isso não é uma opção (por exemplo, você precisa depurar um pacote NuGet), ignore a resposta aceita e vá direto para a seguinte: stackoverflow.com/a/26029208/398630
BrainSlugs83

Respostas:


113

Se você tiver uma referência de projeto , ela deverá funcionar imediatamente.

Se for uma referência de arquivo (dll), você precisará que os símbolos de depuração (o arquivo "pdb") estejam na mesma pasta que a dll. Verifique se seus projetos estão gerando símbolos de depuração (propriedades do projeto => Build => Advanced => Output / Debug Info = full); e se você copiou a dll, coloque o pdb com ela.

Você também pode carregar símbolos diretamente no IDE se não quiser copiar nenhum arquivo, mas é mais trabalhoso.

A opção mais fácil é usar referências de projeto!


3
Infelizmente, acho que não é possível adicionar referência ao projeto a partir de outra solução (corrija-me se estiver errado!).
Elad

7
@ Vlad, acabei de fazer isso. Primeiro adicione "projeto existente" à solução. Em seguida, adicione uma referência ao projeto clicando em adicionar referência do projeto. Você pode definir os pontos de interrupção nos arquivos de projeto existentes. Isso é bom porque os arquivos não são copiados.
user420667

3
Eu tenho o projeto DLL como uma referência do projeto, mas o ponto de interrupção é ignorado.
Slav

1
Na verdade, eu consegui depurar um assembly (release-) hoje que foi adicionado como uma referência de arquivo. Bom para mim, mas como isso aconteceu? O conjunto referenciado do MSVC2010, C #, (ASP) .NET 4.0 existe como depuração + release (mas apenas o release-file foi adicionado ao projeto). Gostaria realmente de esclarecer isso.
Tobias81

1
Para mim, estava funcionando um dia, mas no dia seguinte não estava funcionando (com DLLs e arquivos PDB). Pressionando o botão "Esvaziar cache de símbolos" em Ferramentas> Opções> Depuração> Símbolos, foi corrigido.
Paul

45

Eu tive o mesmo problema. Ele é o que eu encontrei:

1) verifique se todos os projetos estão usando o mesmo Framework (isso é crucial!)

2) em Ferramentas / Opções> Depuração> Geral, verifique se "Ativar apenas meu código (somente gerenciado) NÃO está marcado

3) em Ferramentas / Opções> Depuração> Símbolos, limpe todos os símbolos em cache, desmarque e exclua todos os locais da pasta na caixa de listagem "Locais do arquivo de símbolos (.pdb)", exceto os "Servidores de símbolos da Microsoft" padrão, mas também desmarque-os também. Exclua também todos os caminhos estáticos na caixa de texto "Símbolos de cache neste diretório". Clique no botão "Esvaziar cache de símbolos". Por fim, verifique se o botão de opção "Somente módulos especificados" está marcado.

4) no menu Build / Configuration Manager para todos os projetos, verifique se a configuração está no modo Debug.


3
Meu problema era que meus dois projetos usavam .Net Frameworks diferentes: 4.0 e 4.5. Tx!
User627283

1) e 4) são cruciais. Não se esqueça de criar no modo Debug e usar a mesma estrutura.
22618 scott_f #

12

Outro ponto a ser lembrado, verifique se as DLLs referenciadas não estão instaladas no GAC. Após o teste, instalei minhas dlls no GAC para fazer o teste no nível do sistema. Mais tarde, quando tive que depurar meu código novamente, não pude entrar nos assemblies referenciados até excluí-los do GAC.


2
OBRIGADO! Este foi o meu problema. Não acredito que não resolvi isso: - / Eu pensei que definir a referência do projeto de alguma forma substituiria o que foi instalado no GAC.
precisa saber é o seguinte

Absolutamente! Esse é um ponto muito bom. Mesmo se você tiver a mesma versão do .NET Framework, se você tiver código no GAC ao tentar depurar, ele não atingirá o ponto de interrupção se o arquivo .PDB no GAC for diferente do da pasta do projeto. Uma solução para isso é remover a DLL do GAC, criar e re-GAC o assembly.
DigiOz Multimedia

7

Etapa 1: Vá para Ferramentas -> Opção -> Depuração

Etapa 2: desmarque Ativar apenas meu código

Etapa 3: desmarque a opção Exigir que o arquivo de origem corresponda exatamente à versão original

Etapa 4: desmarque a opção Etapa sobre propriedades e operadores


3

Eu tinha os *.pdbarquivos na mesma pasta e usei as opções do Arindam , mas ainda não funcionou. Acontece que eu precisava ativar a opção Ativar depuração de código nativo, que pode ser encontrada em Propriedades do projeto> Depuração .


1
essa informação deve ter sido incluída na resposta aceita. é o que eu estava procurando especificamente. obrigado por compartilhar! +1
Heriberto Lugo

2

Quando você deseja definir um ponto de interrupção no código-fonte de uma dll referenciada, primeiro verifique se você tem um arquivo pdb disponível para ele. Em seguida, você pode simplesmente abrir o arquivo de código-fonte relacionado e definir um ponto de interrupção por lá. O arquivo de origem não precisa fazer parte da sua solução. Conforme explicado em Como posso definir um ponto de interrupção no código referenciado no Visual Studio?

Você pode revisar seus pontos de interrupção através da janela de pontos de interrupção, disponível em Depuração -> Windows -> Pontos de interrupção.

Essa abordagem tem o benefício de que você não precisa adicionar um projeto existente à sua solução apenas para fins de depuração, pois deixá-lo de fora economizou muito tempo de criação. Evidentemente, construir uma solução com apenas um projeto é muito mais rápido do que construir uma solução com muitos deles.


1
Isso funciona apenas se o arquivo externo onde você colocou o ponto de interrupção corresponder ao caminho exato no PDB. (Por exemplo, só funciona se você construiu a DLL em sua máquina.)
Josh M.

2

Verifique se sua DLL não está registrada no GAC. O Visual Studio usará a versão no GAC e provavelmente não terá informações de depuração.


1

Não quero incluir um projeto de biblioteca de classes externa em algumas das minhas soluções, por isso passo para os assemblies que consumo de maneira diferente.

Minhas soluções têm um diretório "Assemblies comuns" que contém minhas próprias DLLs de outros projetos. As DLLs a que me refiro também têm seus arquivos PDB acompanhantes para depuração.

Para depurar e definir pontos de interrupção, defino um ponto de interrupção na origem do aplicativo consumidor em que estou chamando um método ou construtor do assembly e depois passo INTO (F11) a chamada do método / construtor.

O depurador carregará o arquivo de origem do assembly no VS e novos pontos de interrupção dentro do assembly podem ser definidos nesse ponto.

Não é simples, mas funciona se você não deseja incluir uma nova referência de projeto e simplesmente deseja fazer referência a uma montagem compartilhada.


0

Isso deve funcionar. Eu costumava depurar um arquivo .exe e uma dll ao mesmo tempo! O que eu sugiro é 1) Inclua o caminho da dll no seu projeto B, 2) Em seguida, compile em depurar o seu projeto A 3) Controle que o caminho aponte no arquivo A dll e de pdb .... 4) Depois disso, você inicie na depuração do projeto B e, se estiver tudo bem, você poderá depurar nos dois projetos!


0

A maneira mais direta que encontrei usando o VisualStudio 2019 para depurar uma biblioteca externa à qual você está fazendo referência no NuGet é executando as seguintes etapas:

  1. Ferramentas> Opções> Depuração> Geral> Desmarque 'Ativar apenas meu código'

  2. Vá para Assembly Explorer> Abrir no cache de pacotes do NuGet Item da lista

  3. Digite o nome do pacote NuGet que você deseja depurar no campo de pesquisa e clique em 'OK' insira a descrição da imagem aqui

  4. No Assembly Explorer, clique com o botão direito do mouse no assembly importado e selecione 'Generate Pdb' insira a descrição da imagem aqui

  5. Selecione um caminho personalizado no qual deseja salvar o arquivo .PDB e a estrutura para a qual deseja que isso seja gerado.

    insira a descrição da imagem aqui

  6. Copie o arquivo .PDB da pasta gerada para sua pasta Debug e agora você pode definir pontos de interrupção no código de biblioteca deste assembly


Parece bom, exceto que não consigo encontrar nenhum Assembly Explorer; não faz parte do Resharper?
Robert Massa
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.