Erro “There was a problem loading your Microsoft Azure settings. Please try importing your subscription settings again” no Visual Studio

Say "edge case" again. I dare you! Bem… Na verdade acho que esse é um edge case, sim. Mas ainda assim sempre acontece comigo, então acho que é hora de blogar e não esquecer mais!

Continue lendo “Erro “There was a problem loading your Microsoft Azure settings. Please try importing your subscription settings again” no Visual Studio”

Para que servem os arquivos PDB?

Página de configuração de símbolos na caixa de diálogo Tools | OptionsVocê sabe para que servem os arquivos PDB? Se as enquetes informais que faço durante meus treinamentos servem de indicador, então arriscaria dizer que a maioria dos desenvolvedores .NET não sabem.

Invariavelmente, as respostas que recebo à pergunta-título deste post variam entre uma das duas opções abaixo:

“Servem para poder debugar [sic] os programas. Por isso eles só são gerados quando compilamos em modo Debug.”

“Não servem para nada. Ou melhor, servem para ser apagados assim que são criados.”

Bom, é hora de explicar isso um pouco melhor.

A história por trás do PDB

Arquivos PDB (acrônimo de Programa Database) foram criados pela Microsoft para facilitar o processo de depuração de aplicações C++.

O grande desafio de se depurar uma aplicação C++ (ou qualquer outra linguagem que seja compilada para código nativo) é que, uma vez gerado o código nativo (seja um EXE ou uma DLL), tudo o que temos são instruções opcodes (instruções de baixo nível) e ponteiros. Em outras palavras, nada que nos permita executar um programa linha-a-linha e inspecionar o valor de suas variáveis.

Para uma execução linha-a-linha, como a que temos no Visual Studio, precisaríamos basicamente de:

  1. Uma lista com os nomes de variáveis e seus endereços correspondentes na memória. Assim, quando o depurador encontrasse um ponteiro de memória, ele saberia a que variável aquele endereço corresponde;
  2. Uma outra lista com os nomes dos arquivos de código-fonte, seus números de linha e o endereço de memória correspondente. Assim, quando o depurador fosse executar uma instrução num determinado endereço de memória, saberia a qual linha ele corresponde e poderia exibi-la na tela.

O compilador tem condições de gerar todas essas informações. A dúvida era: Onde armazena-las? Guardar essas informações dentro do próprio arquivo binário não faria sentido, afinal geraria um overhead desnecessário. Os arquivos ficariam muito grandes, recheados de informações que só seriam úteis durante uma sessão de depuração. Veio daí a ideia de criar um arquivo auxiliar para armazenar essas informações: o arquivo PDB.

Introduzidos juntamente com o Visual C++ 1.0, os arquivos PDB armazenam as seguintes informações (metadados) de um binário C++:

  • Símbolos públicos (tipicamente todas as funções, variáveis estáticas e variáveis globais);
  • Uma lista dos objetos que são responsáveis por seções de código no arquivo executável;
  • Informações de Frame-pointer omission (FPO);
  • Informações sobre nome e tipo de dados para variáveis locais e estruturas de dados;
  • Informações sobre nome de arquivo-fonte e número de linha.

Com isso, depurar código C++ ficou muito mais fácil. O Visual Studio tem um banco de dados repleto de informações detalhadas sobre nossos arquivos executáveis, sem que isso gere um overhead desnecessário ao coloca-los em produção.

Arquivos PDB e o .NET

Arquivos executáveis em .NET (os assemblies) são completamente diferentes de suas contrapartes em código nativo. Ainda que tenham as mesmas extensões (EXE e DLL), sua estrutura interna é bem diferente. Não apenas pela linguagem (MSIL vs. código nativo) mas principalmente pela presença de metadados. Assemblies .NET são ricos em metadados. São eles que permitem, por exemplo, que possamos fazer reflexão (reflection) sobre nossos objetos. Ou seja, grande parte das informações que um PDB nativo precisa armazenar ao compilarmos aplicações C++ já está presente dentro do próprio assembly .NET, sendo portanto redundantes. Para o .NET, os arquivos PDB contêm apenas:

  • Informações sobre nomes e endereços de variáveis locais; e
  • Informações sobre nome de arquivo-fonte e número de linha.

Parece pouca coisa, né? Mas é fácil perceber a diferença entre a presença e a ausência de um arquivo PDB. Mas antes de mais nada, conheça nosso pequeno aplicativo-teste:

image
432

Agora vamos executa-lo duas vezes. Na primeira manteremos o arquivo PDB junto ao executável. Já na segunda, excluiremos o arquivo antes de executar nosso aplicativo.

Veja as duas mensagens de erro e seus respectivos stack traces. Note como, na ausência do PDB (na segunda figura), não é possível saber as linhas dos métodos na pilha:

SNAGHTMLc859bdd
130

SNAGHTMLc85f279
130

E isso não tem nada a ver com o aplicativo ter sido compilado em modo Debug ou Release. Veja abaixo que, mesmo compilando em modo Release (repare no caminho na barra de títulos da janela), o nome de arquivo e a linha são exibidos:

SNAGHTMLc863166
130

SNAGHTMLc864f2f
130

Agora, a parte mais legal: a utilidade dos PDBs vai muito além do F5 de uma típica sessão de depuração. Os PDBs se mostram realmente úteis quando usados para diagnosticar problemas em… produção!

PDBs em Produção

Existem várias ferramentas que ajudam a diagnosticar problemas em produção: desde o tradicional crash dump até os modernos IntelliTrace e System Center Operations Manager (SCOM) APM. Dessa forma, exceções sendo disparadas em produção poderiam ser capturadas em produção e corrigidas em desenvolvimento, sem necessidade de intervenção direta do time de desenvolvimento.

Entretanto, se você não tiver os PDBs, seu crash dump ou seu log do IntelliTrace serão praticamente inúteis, pois você não conseguirá correlacionar o binário em produção com o código-fonte em desenvolvimento.

Isso significa que, quando eu colocar uma aplicação em produção, devo colocar os PDBs em produção também? Bem, a resposta não é tão óbvia assim. Smile

Vamos por partes:

  1. Os arquivos PDB são importantes?
    Sim, muito! Para todos os efeitos, considere que os arquivos PDB são tão importantes quanto seus binários EXE e DLL.
  2. Quer dizer que devo sempre manter os PDBs, mesmo quando coloco minha aplicação em produção?
    Sim, deve. Mesmo quando compila seu binário em modo Release.
  3. Então devo copiar meus PDBs para o ambiente de produção, junto com os binários, sempre que fizer uma implantação?
    É aqui que as coisas começam a ficar um pouco mais confusas. Como já falamos, você deve guardar o PDB. Entretanto ele não deveria ir para a produção. Ele não é útil lá – e além disso pode representar uma vulnerabilidade de segurança, deixando à disposição informações sobre seu código-fonte que deveriam estar disponíveis apenas em desenvolvimento.
  4. Então onde eu guardo meus PDBs se não posso copia-los para produção?
    É para isso que você deveria ter um servidor de símbolos (symbol server) em sua empresa.

Servidor de Símbolos

Um servidor de símbolos, apesar do nome pomposo, é simplesmente um compartilhamento de rede onde você armazena e versiona seus PDBs.

Vou falar mais sobre servidores de símbolos – como instalar, configurar e atualizar – mas isso fica para o próximo post.

Um abraço,
Igor

Como navegar rapidamente no Visual Studio

Se você é como eu e prefere usar o teclado ao invés do mouse, certamente vai curtir muito esta dica:

Para navegar entre os diversos elementos de uma solução (solution) do Visual Studio, pressione a tecla de atalho Ctrl+, (a tecla Control e a tecla “vírgula”) para acessar a caixa de diálogo Navigate To. Daí, é só começar a digitar um pedaço do nome do item que você quer acessar. Pode ser um arquivo, método, classe… Qualquer parte da solution pode ser facilmente acessada dessa maneira!

Caixa de diálogo Navigate To
480

 

Um abraço
    Igor

Mudanças na ferramenta de ALM para bancos de dados no Visual Studio “11”

A Microsoft introduziu, em 2005, uma ferramenta com uma proposta revolucionária: integrar o desenvolvimento de bancos de dados ao ciclo de vida da aplicação.

Nascia então o “Visual Studio 2005 Team Edition for Database Professionals” (*), que oferecia recursos como controle de versão para a estrutura (“schema”) de bancos de dados, testes de unidade para código de bancos de dados (ex. stored procedures e queries), geração de dados e mais.

Quando a Microsoft lançou o Visual Studio Team System 2008, renomeou o produto para “Visual Studio Team System 2008 Database Edition”. Até aqui, o DbPro (como era conhecido o produto) era um vendido à parte – ou seja, para usar esses recursos de DDLC (Database Development Lifecycle) era necessário adquirir o VSTS Database Edition ou o venerável VSTS Team Suite (que incorporava todos os recursos disponíveis na plataforma Team System).

O problema é que, diferente do que o time de produto tinha imaginado, o grande usuário dessa ferramenta não era o DBA, mas sim o próprio desenvolvedor. Afinal, é ele quem precisa modificar o banco de dados sempre que necessário, como parte do processo de construção da aplicação. Com isso os desenvolvedores acabavam tendo que comprar duas ferramentas (VSTS 2008 Development Edition e VSTS 2008 Database Edition) para suas atividades do dia-a-dia. Desnecessário dizer que ninguém estava feliz com isso…

imageEm 2010 veio a primeira grande mudança de posicionamento do produto. A Microsoft, a partir do feedback recebido dos clientes, decidiu juntar as duas ferramentas – VSTS Development Edition e Database Edition – num único produto: o novo Visual Studio 2010 Premium. Além da integração, veio também a possibilidade de gerenciar bancos de dados Oracle em complemento ao suporte original a SQL Server.

Ficou confuso com essa viagem no tempo? É, não é para menos… A ferramenta originalmente conhecida como DbPro (codinome “DataDude”) passou por muitas mudanças desde que foi lançada. A única constante era o fato de que, para usar a ferramenta, era necessário comprar um produto “premium” (Team System até 2008, VS Premium/Ultimate no 2010). E como se não bastassem tantas mudanças, vem aí mais uma mudança radical:

image
142

SQL Server Data Tools (anteriormente conhecido como SQL Server Developer Tools, codinome “Juneau”) representa a nova versão da ferramenta de banco de dados anteriormente conhecida como DbPro, DataDude, VSTE for Database Professionals, VSTS Database Edition…

Reparou numa coisa estranha? Sim, agora o DbPro não é mais parte do Visual Studio. Os recursos de bancos de dados foram movidos para o SQL Server.

“Putz, agora ferrou tudo!!!” foi minha reação ao ficar sabendo da mudança. Mas antes de entrar em pânico, entenda o que muda:

  • Pontos positivos:
    • O DbPro/SSDT agora é gratuito. Sim, você leu direito. Gratuito. Você pode baixar o SSDT do site da Microsoft e usá-lo com qualquer SQL Server ao qual você tenha acesso;
    • Pode ser usado independentemente ou integrado ao Visual Studio (2010 ou Dev11). Mesmo se o seu Visual Studio for o Professional (mas não Express).
  • Pontos negativos:
    • Como é um novo produto, ainda não está claro quais são as implicações da migração da ferramenta do time de Visual Studio para o time do SQL Server. Agora é aguardar o lançamento do SQL Server 2012 para termos certeza do que mudou (se é que mudou).

Para mais informações sobre o SSDT, leia o post do Gert Drapers (o Data Dude original, pai do DbPro/”DataDude”):

http://blogs.msdn.com/b/gertd/archive/2011/10/17/sql-server-developers-tools-code-named-juneau-becomes-sql-server-data-tools-ssdt.aspx

Um abraço,
    Igor

(*) Estou para ver empresa que goste de nome de produto comprido como a Microsoft!