na internet a resposta centralizada, onde eu pudesse concluir a dinamica da coisa, decidi escrever este post. Entao, vamos comecar pelo principio.Conceito Basico de um Symbol/Source ServerAntes de tudo, apesar do nome bonito, um Symbol Server basicamente nao passa de um diretorio onde um depurador pode procurar pelos arquivos .pdb. Basicamente nestes arquivos ficam armazenadas as informacoes necessarias para a depuracao, fazendo um mapeamento entre o binario do assembly e as linhas no script no arquivo fonte. Quando depuramos a nossa aplicacao, o depurador realiza uma busca a um arquivo .pdb, que possua o mesmo nome do assembly (e.g. se o assembly e xpto.dll, entao ele procura por xpto.pdb). Esta busca e realizada basicamente na seguinte ordem:no diretorio do assembly;no diretorio do windows;no diretorio %windir%\symbols\dllno diretorio %windir%\dllno cache do Visual Studio (configurado em Options > Debugging > Symbols)no Symbols Locations configurados no Visual Studio (configurado em Options > Debugging > Symbols)Isso significa que se eu criar um diretorio c:\temp\symbols, colocar ali o arquivo 'assembly.pdb' e configurar este diretorio como um Symbol Location no Visual Studio, quando eu depurar 'assembly.dll' referenciada na minha aplicacao o Visual Studio vai encontrar o pdb/symbols.Neste momento os simbolos estariam carregados, mas isso ainda nao quer dizer que conseguriamos depurar o nosso assembly. Assim seria porque o que o depurador encontraria no .pdb e apenas a referencia de onde esta localizado o arquivo fonte utilizado na compilacao. E aqui esta algo que e um grande problema nesses arquivos: as referencias a estes arquivos estao armazenados usando um caminho absoluto (e.g. C:\meuprojeto\minhaclasse.cs). Isso leva a dois problemas: O primeiro e que, se nos compilassemos o assembly num Build Server, ao depurar na maquina de desenvolvimento o depurador nao iria encontrar o arquivo fonte (obviamente partindo do principio de que nas duas maquinas o projeto esta configurado em diretorios de caminhos absolutos diferente). O segundo problema acarretado e que se nos versionassemos e compilassemos um assembly, por exemplo, 3 vezes, neste caso os tres arquivos .pdb gerados apontariam para o mesmo arquivo fonte fisico, o que me impossibilitaria a depuracao dos pacotes de versoes antigas, pois eu sempre teria apenas a ultima versao do codigo em disco.Assim, se o arquivo fonte existir na maquina de desenvolvimento, OK; caso contrario, o Visual Studio vai pedir pra voce indicar a localizacao do aquivo.Como montar um Symbol/Source Server BasicoUm Symbol Server de verdade precisa ter o controle das versoes dos .pdb's de um assembly, e atuar tambem como um Source Server, contendo o codigo fonte correto para a versao do assembly. Uma vez que o codigo fonte e carregado junto com o .pdb, e necessario ajustar a referencia absoluta que estes aquivos possuem ao fonte. Este processo e chamado de Source Indexing. Mais a frente eu explico como este processo pode e sera realizado; permita-me por hora ater apenas a teoria.Depois da indexacao do fonte, nos precisariamos organizar o nosso Symbol Server (que por hora e um diretorio numa pasta, lembra)? por versao. Lembra-se do processo de busca que o depurador faz para encontrar o .pdb? Entao... tem algo que eu nao disse: