Como os scripts nant que compilam esses projetos, utilizam as variáveis de ambiente do Visual Studio,
definidas no arquivo “vcvarsall.bat”. Quando a compilação era disparada de dentro do Cruise Control.Net ocorriam erros,
devido não ser possível encontrar as bentidas variáveis de ambiente.

O problema é que eu não consegui achar um meio de fazer com que o serviço do Cruise Control tivesse acesso as variáveis de ambientes
definidas pelo arquivo batch do Visual Studio.

O jeito foi seguir o aconselhado no site do Cruise Control.Net e seguir a vida. Até que esta semana conversando com o Wanderley, ele deu a idéia de utilizar o Prog2Svc feito pelo Fernando para fazer com que o serviço do Cruise Control tivesse acesso as variáveis de ambiente.

Dessa forma o arquivo batch que inicializa o serviço do Cruise Control ficou dessa maneira:

call "C:\\Program Files\\Microsoft Visual Studio 8\\VC\\vcvarsall.bat" x86
cd "C:\\Program Files\\CruiseControl.NET\\server"
"C:\\Program Files\\CruiseControl.NET\\server\\CCNET.exe" -remoting:on

E a linha de comando para fazer com que o Prog2Svc registre o arquivo batch como serviço foi o seguinte:

c:\\windows\\system32\\Prog2Svc.exe -add C:\\windows\\system32\\CCNetServer.Bat

O único problema é que foi necessário alterar o usuário que roda o serviço criado pelo Prog2Svc de SYSTEM
para um usuário local da máquina de compilação, por ocorrer um problema de compilação nos projetos C/C++ “Program Database Mismatch”
que é descrito aqui.

Agora vamos lá, quem é o discipúlo do Ninja Gaiden que consegue descobrir por que diabos uma aplicação está derrubando seu IIS a cada 5 minutos
sem gerar um misero arquivo de log. Numa situação dessas ter o Visual Studio instalado e atachado no processo do IIS seria o cenário ideal, mas devido
as restrições acima mencionadas não é possível.

Mas não desanime, existe uma ferramenta que pode te ajudar e muito nessas situações é o DbgCLR. Essa ferramenta está localizada no diretório,
%ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\GuiDebug\DbgClr.exe. Essa ferramenta é um Visual Studio bem mirradinho, mas que dá conta do
recado quando o que você precisa é efetuar uma depuração urgente.

Interface do DbgClr

O DbgClr pode ser copiado para o computador onde sua aplicação está instalada e ai é só executar. A única exigência, é que você tenha os fontes da
aplicação e os simbolos referentes a versão da aplicação que está rodando no computador a ser depurado. Com isso em mãos sua experiência de depuração
será bem mais tranquila.

Legal, mas como eu utilizo essa bomba?

Coloque os fontes da aplicação em um diretório da máquina onde a aplicação está instalada e copie os simbolos da aplicação para o diretório Bin da sua
aplicação. Feito isso, execute o DbgClr.exe e selecione a opção File -> Open -> File e selecione todos os arquivos .cs ou .vb da sua aplicação.

Após abrir fontes da sua aplicação e definido os breakpoints desejados. Selecione a opção Tools -> Attach to process, uma nova janela será
exibida onde você poderá selecionar o processo do IIS a ser depurado, que é o w3wp.exe. Lembre-se que para cada Application Pool o IIS cria uma
instância do processo w3wp.

Abraços.

Costumo ler muitos, muitos blogs, o que muitas vezes consome um certo tempo do meu horário de trabalho, espero que meu gerente não leia isso. Mas nos últimos 3 anos, blogs tem sido a melhor forma pra mim de me manter atualizado. Claro, blogs não são o “Holy Grail” do conhecimento, mas ajudam e muito. Por isso, blog é uma coisa que prentendo continuar lendo nos próximos 6 meses, mesmo isso não me fazendo um melhor programador, me deixam por dentro do que está acontecendo no mundo da tecnologia de um modo geral.

Contato com programadores de outras plataformas e linguagens de programação é também uma forma excelente de se tornar um melhor programador, já que você vai sempre ver os pontos de vista de diversos ângulos.

Na Open, empresa que trabalho, é o lugar certo pra isso, não querendo vender o peixe da empresa. Mas lá temos contato com diversos tipos de tecnologias e plataformas, como desenvolvimento de Device Drivers, Engenharia Reversa de Trojans, desenvolvimento de aplicações para celulares e claro .Net.

Pra ser sincero não tenho um super plano pra me tornar um melhor programador nos próximos 6 meses, mas tenho algumas coisas que preciso fazer:

• Tenho uma pequena pilha de livros pra ler, então pretendo terminar ela, ou chegar a metade.
• Postar mais frequentemente.
• Aprender a organizar melhor meu tempo.
• Roubando um parágrafo do blog do Fernando: “Andar de bicicleta e ir à praia também fazem parte da formação de programadores excelentes.”

Bem, é isso. Espero ter pago minha dívida junto ao Wanderley.

Abraços.

Let´s get down to business.

Após instalar o SP 1 do Visual Studio 2005, fiquei um tempo sem ter que trabalhar em um projeto que usa extensivamente relatórios feitos em Crystal Reports. Semana passada, quando tive que efetuar uma alteração em um dos relatórios desse projeto, abri a solução rodei o projeto e vejam a tela bacaninha que pipocou.

Legal, não?

A única pista que eu tinha até o momento era o bendito CLSID {11BD5260-15B6-412D-80DB-12BB60B8FE50}, abri o regedit e fiz uma procura por esse CLSID, o que me deu uma pista um pouco melhor de quem poderia ser o culpado de toda essa bagunça. Imagem abaixo mostra que esse CLSID se refere á uma biblioteca do Crysta Reports chamada sacommlayer.dll.

Procurei a abençoada da sacommlayer.dll no caminho que estava no Registro, C:\Arquivos de programas\Arquivos comuns\Business Objects\2.7\Bin\, para minha não muita surpresa, a criatura não estava lá. Entrei em uma outra máquina que o Service Pack 1 não tinha sido instalado, e como eu aprendi que tudo na vida só a violência constrói, copiei todas as dlls existentes no diretório onde a sacommlayer.dll se encontrava para a minha máquina.

Tentei acessar novamente a página em que o relatório estava dando problema e dessa vez a página abriu sem problemas. Antes a página que tinha o componente do Crystal Reports nem abria, agora já estava abrindo. Apliquei alguns filtros no relatório e mandei executar e para minha não grande surpresa novamente mais um problema.

Como vocês podem ver pela imagem, por algum motivo na minha super cópia de arquivos de uma máquina para outra, eu devo ter esquecido de incluir essa tal de crpe32.dll. Entrei no diretório C:\Arquivos de programas\Arquivos comuns\Business Objects\2.7\Bin\, e a dll estava lá. Imaginei que aquele não seria o local correto dessa dll, para tirar essa dúvida abri o FileMon e apliquei o filtro para crpe32.dll. Para minha supresa o FileMon não “pegava” nada, então possivelmente a excessão estava ocorrendo no lado gerenciado.

Se nós dermos uma olhada na stack trace da última imagem, podemos ver que a excessão foi lançada no construtor da classe CrystalDecisions.CrystalReports.Engine.CRPE. Abrindo o Reflector e tentarmos localizar o assembly CrystalDecisions.CrystalReports.Engine, não será possível. Não sei o motivo, mas para resolver isso tem um jeitinho.

Abra o prompt e navegue até o diretório, %windir%\Assembly\GAC_MSIL\CrystalDecisions
.CrystalReports.Engine\10.2.3600.0__692fbea5521e1304, e lá estará a CrystalDecisions.CrystalReports.Engine.dll. Copie a dll para um outro diretório fora dessa árvore de diretórios e será possível abrir esse assembly pelo Reflector.

Ufa, depois de tudo isso vamos voltar ao nosso problema.

Navegando pelo Reflector será possível ver que existem dois construtores para essa classe, um estático e ou de instancia, abra o construtor estático e veremos a imagem a seguir.

A linha marcada em vermelho chama o método estático CRPE.GetDllPath() que pode ser a nossa fonte de respostas, abrindo o código desse método no Reflector temos o seguinte:Opa, agora sim hein, parece que esse método “descobre” o caminho da crpe32.dll acessando a seguinte chave no registro HKLM\SOFTWARE\Crystal Decisions\10.2\Crystal Reports e procurando pelo caminho contido no valor CommonFiles, entrando no registro da minha máquina, como mostra a imagem abaixo, não existe o valor CommonFiles.