Ricardo Serradas

Olá,

Desde meus primeiros contatos com o WebTest Recorder do Visual Studio Team System, identifiquei que problemas aconteciam com ele com frequência e, por conta disso, perdia tempo correndo atrás de uma solução a cada vez que isso acontecia.

E ontem aconteceu denovo. Eu, com uma instalação completa e atualizada do VS 2008 Team Suite, não conseguia ver a barra do WebTest Recorder no Internet Explorer 8. Fazendo uma pesquisa rápida, encontrei um post do Michael Taute que compila soluções para diversos tipos de problemas referentes ao plugin. Você pode ler o post na íntegra em:

http://blogs.msdn.com/mtaute/archive/2007/11/09/diagnosing-and-fixing-web-test-recorder-bar-issues.aspx

Porém, um dos problemas me chamou a atenção ontem, depois de ter passado por ele. O cenário é o seguinte:

• Windows 7 64 Bits
• Visual Studio 2008 Service Pack 1 Up-To-Date
• Internet Explorer 8

O add-on do webtest recorder estava habilitado no navegador e, mesmo assim, a barra não aparecia. Veja a solução apontada pelo Michael:

O Windows Vista faz cache da lista de barras disponíveis para o Internet explorer e a barra do gravador não estava disponível na sua lista. A correção consiste em forçar o Windows a reconstruir este cache. Para fazer isso, primeiro certifique-se que você está sem nenhuma janela do Internet Explorer aberta e então abra o editor de registros do Windows (Regedit) e exclua as seguintes chaves:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021493-0000-0000-C000-000000000046}

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021494-0000-0000-C000-000000000046}

Nota: Por padrão, o editor de registro 32 bits está localizado em %WINDIR%\SysWow64\RegEdt32.exe

Vamos aguardar e torcer para que a ferramenta de testes web do Visual Studio 2010 seja mais estável

[]‘s

Ricardo Serradas

Olá a todos,

Depois de muito tempo, volto a escrever. Tem sido uma dura correria que me impossibilitou de dar atenção a este valioso espaço. Porém, mais uma vez, prometo tentar reservar um pouco do meu tempo para enriquecer o conteúdo desta página.

Volto hoje com um assunto que não costumo discutir aqui no blog, que é codificação.

Ultimamente tenho ocupado quase que todo o meu tempo com estudos e discussões sobre a melhor forma de codificar algo. Um problema que encontrei dias atrás foi uma limitação do LINQ To Entities, que não implementou um método mapeado para a função “IN” do SQL. Um exemplo: quero obter todos os usuários do banco cujo ID é um dos números da sequência mística do seriado LOST, que é: 4, 8, 15, 16, 23, 42. A query SQL seria:

SELECT * FROM USER U WHERE U.ID IN (4, 8, 15, 16, 23, 42)

Em tese, uma expressão LINQ para fazer a mesma coisa seria mais ou menos assim:

string[] ids = { “4″, “8″, “15″, “16″, “23″, “42″ };

var users = (from t in _db.User where ids.Contains(t.Id.ToString()) select t).ToList();

Em tempo de compilação, tudo certo. Porém, ao executar este código, você receberá esta mensagem de erro:

LINQ to Entities does not recognize the method 'Boolean Contains(Int32)'

É possível estender as bibliotecas do LINQ para mapear a função, criar uma função ultra-complicada para fazer isso, mas há uma maneira de resolver com uma linha de código, que é:

var users = _db.User.Where("it.Id IN {" + string.Join(",", ids) + "}");

Atenção para a palavra chave “it”, ela representa sua entidade na query. Logo, Id é a propriedade.

Experimente!

[]‘s

Ricardo Serradas

Olá a todos! Hoje vamos falar de mais um capítulo da série “Problema e solução”.

Problema:

Ao configurar uma Team Build no VSTS de um projeto que compila e que roda os testes unitários tudo certinho, a build roda, porém o status dela fica como “Partially Succeeded” porque os testes unitários falharam e, ao analisar o log, você encontra a seguinte linha no final:

MSBUILD : warning MSB6006: “MSTest.exe” exited with code 1.

O mais interessante é que se você roda os testes unitários a partir do Test List da Solution, todos funcionam, não é?

Causa:

Pois bem. Por algum motivo, o erro se dá por conta do usuário TFSSERVICE* não ter permissão na pasta onde o resultado do build foi colocado (ou “dropado”).

Solução:

Basta permitir escrita (tanto NTFS quando de compartilhamento) para pra o usuário TFSSERVICE na pasta de build drop.

*Este nome pode variar de acordo com a instalação realizada.

[]‘s

Ricardo Serradas

Mais um erro comum depois de criar uma nova instalação do servidor do VSTS é aquele que você visualiza logo ao iniciar a máquina, dizendo algo como “Alguns serviços não puderam ser inicializados adequadamente. Consulte o visualizador de eventos…”.

Então, a primeira iniciativa que tomamos é olhar qual serviço com modo de startup automático não foi inicializado.

Chegando lá no snap-in de serviços, conferimos que o serviço “Visual Studio Team Foundation Server Task Scheduler” (TFSServerScheduler) não está inicializado. Vamos lá então: iniciamos ele manualmente e… Ele inicia! E fica lá, rodando normalmente. Mas oras, então porque ele não conseguiu subir no startup da máquina?

Consultando o Event Log, encontramos a seguinte mensagem de erro:

TF53010: The following error has occurred in a Team Foundation component or extension:

(…)

Application Domain: TFSServerScheduler.exe

(…)

Detailed Message: Unable to connect to the remote server

O que acontece?

O TFSServerScheduler depende tanto do SQL Server quanto do IIS para funcionar. Logo, se um dos dois serviços ainda não estiver devidamente inicializado, o TFSServerScheduler não vai conseguir ser inicializado também.

Como contornar isso?

Basta configurar o serviço TFSServerScheduler para ser dependente dos serviços do SQL e do IIS. Assim, ele só fará tentativas de inicialização depois que os dois serviços os quais ele depende estejam devidamente no ar. Para configurar isso, use a seguinte linha de comando no Command Prompt:

sc config TFSServerScheduler depend= W3SVC/MSSQLSERVER

Reinicie o servidor para conferir. O serviço estará devidamente inicializado.

[]‘s

Ricardo Serradas

Está aí mais um código de erro que vem incomodando logo depois de uma instalação nova e completa de um servidor do VSTS é feita. A mensagem de erro é encontrada no Visualizador de Eventos (Event Viewer) do Windows e é exatamente assim:

TF15003: The cache root specified in the fileCacheRoot configuration value must be an absolute (rooted) path. File caching will be disabled.

Isso soa falha no processo de instalação e a causa nada mais é do que a pasta que está sendo apontada como cache no arquivo de Configuração do WebService de Version Control do TFS não existir. Como conferir isso? Veja:

- Acesse a pasta de instalação do TFS e edite o arquivo Web.Config, comumente em:

C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\VersionControl\Web.Config

- Encontre a chave “fileCacheRoot”, dentro de “AppSettings” e confira se a pasta para a qual a chave está apontando existe. No meu caso, apontava para:

C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\VersionControl\Data

Se a pasta realmente não existir, basta criá-la. Após isso, reinicie os serviços e confira se a mensagem de erro aparece de novo no Event Viewer. Se não aparecer mais, pronto! Seu serviço de controle de versão voltará a trabalhar com cache.

[]’s

Ricardo Serradas

Numa instancia recém instalada do TFS 2008, onde tudo parecia estar funcionando 100%, encontrei um problema o qual percebi ter pouca referência à respeito.

Criei uma solution de testes para armazenar no Source Control, adicionei projetos, tudo tranqüilo. Depois de tudo, parti para a configuração de um Team Build.

A solução compilava normalmente na máquina client, porém, depois que subi a solução no TFS o team build falhou. Veja a mensagem de erro:

Error MSB4019: The imported project [TargetPath] was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

O erro era vinculado sempre à Web Projects (Web Application, WebService, etc). Isso ocorre porque os targets para aplicações web não estão instaladas no servidor de build.

Existem duas formas de resolver o problema. Uma delas (e a que eu aconselho) é simplesmente instalar o Visual Studio 2008 com as mínimas opções (C# e Visual Web Developer) no servidor de build. O ponto negativo desta solução é que estará consumindo espaço em disco do servidor de build.

A outra opção, se não quiser instalar o VS 2008 no servidor é a seguinte:

- Acesse: MSBuild\Microsoft\VisualStudio\v9.0\WebApplications na máquina client;

- Copie Microsoft.WebApplication.targets para o diretório da solução do projeto;

- Adicione o arquivo como parte da solução e versione-o;

- Edite o arquivo TFSBuild.proj da sua WebApplication usando um editor de texto (normalmente em [TeamProject]/TeamBuildTypes/[SolutionName]Build);

- Encontre a linha que faz o import do WebApplication Target a partir da pasta do MSBuild no Program Files:

<Import Project=”$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets” />

E substitua por:

<Import Project=”$(SolutionDir)\Microsoft.WebApplication.targets” />

- Salve seu arquivo e suba a nova versão no TFS.

Esta solução nada mais faz do que disponibilizar o arquivo de target dentro da própria solution para que o MSBuild o busque lá dentro. O ponto negativo desta é que para cada solução que você for versionar que tiver um Web Project será necessário versionar uma cópia do arquivo de target no TFS.

Escolher a melhor opção para seu cenário é com você. Experimente!

Um abraço,
Ricardo Serradas

Seguindo minha saga de estudos no VSTS 2010, encontrei mais um problema: o erro TF30224 ao tentar criar um novo projeto no TFS.

A mensagem de erro, depois que descobrimos a solução, é bem clara: “verifique se o servidor SQL está no ar ou se você tem permissão para acessá-lo“. Não é bem o servidor SQL, e sim o servidor de relatórios, o Report Server.

Ao acessar http://[TFSSERVER]/Reports com o TFSSETUP (usuário que usei para instalar todo o TFS) vi que não conseguia enchergar nada. Como resolver isso? Acessando a mesma URL porém autenticando-se como o Administrador local do servidor.

Pronto! Só atribuir permissão de Content Manager para o TFSSETUP (ou o usuário que está usando para criar o projeto, o seu “TFS Admin”) assim:

- Acesse http://[TFSSERVER]/Reports como orientado acima;

- Clique na aba “Propriedades”;

- Clique em “Atribuição de nova função”;

- Em “Nome do grupo ou usuário”, digite o usuário que necessita da permissão (no meu caso, [TFSSERVER]\TFSSETUP);

- Em “Função”, selecione “Content Manager” e em seguida clique em OK.

E pronto! Você conseguirá prosseguir com a criação do Team Project.

[]’s

Ricardo Serradas

Olá pessoal,

Hoje instalando o TFS 2010 num ambiente single server me deparei com dois problemas que não estão previstos no TFSInstall.chm, que vem no DVD de instalação do TFS.

O primeiro erro foi que não há web.config em “C:\Program Files\Microsoft Team Foundation Server 10.0\Application Tier\Web Services”.

Solução: É preciso criar uma cópia do web.config.template já existente lá.

Segundo erro: Visualizado no wizard de configuração padrão do TFS. Veja:

Error [ Configuration Database ] TF255147: The following server that is running SQL Server is not listening on the expected TCP port: TFS01.

As portas necessárias já estavam liberadas, a instancia do SQL já estava rodando… O que fazer? Foi então quando me lembrei de dar uma olhada nas configurações do SQL 2008 (em Start > All Programs > Microsoft SQL Server 2008 > Configuration Tools > SQL Server Configuration Manager)  e lá vi que o protocolo TCP/IP não estava habilitado (e não vem habilitado por padrão numa instalação do SQL).

O que fiz então foi habilitar o protocolo, com um duplo clique em TCP/IP e na aba Protocol, mudar a propriedade Enabled para Yes.

Feito isso, voilá! O teste de configurações rodou 100%! Mas, há um porém… Se a instalação do TFS for interrompida por algum motivo (no nosso caso, pelo SQL não estar corretamente configurado) a instalação do Sharepoint Services será corrompida. Isso é um bug conhecido do Beta1 do TFS.

Por conta disso, mãos à obra! Desinstalar todo o TFS + WSS e começar denovo. Então, dessa vez, tudo correrá bem. 

Um abraço!

Ricardo Serradas

Bom dia pessoal.

Hoje o que me fez elaborar mais um post não é uma novidade muito agradável.

Em testes que estava fazendo no provider do TFS (que postei sobre ele dias atrás), encontrei problemas quando temos um cenário em que ainda se faz necessário o uso do Source Safe.

Após a instalação do provider, não foi possível voltar a usar o Source Safe novamente através de um Switch de fontes de código amigável na IDE do Visual Studio 2003.

Para poder usar o VSS novamente sem desinstalar o Provider do TFS, foi necessário modificar a chave de registro “ProviderRegKey” que se encontra em:

[HLM\Software\SourceCodeControlProvider\ProviderRegKey]

O novo valor atribuido tem que ser o caminho de registro do Source Safe, que por default é:

“Software\Microsoft\SourceSafe”

Este valor pode ser encontrado na chave “Microsoft Visual SourceSafe”, contida em:

[HLM\Software\SourceCodeControlProvider\InstalledSCCProviders]

Se quiser voltar a usar o TFS Provider, basta voltar o valor da chave “ProviderRegKey” para o mesmo valor da chave “Microsoft Team Foundation Server MSSCCI Provider”, encontrada na localização informada logo acima.

Abraço galera.

Ricardo Serradas

Algo que causa muita preocupação e muito planejamento em empresas que pensam em migrar do VSS para o Team Foundation server é justamente a migração do código-fonte.

Há os que pensam que vão perder o histórico, outros que vão ter que recolocar os fontes no sourcecontrol manualmente, e por aí vai. O legal é destacar que o TFS conta com uma ferramenta chamadaVSSConverter, que colabora com essa migração.

Esta ferramenta transporta entre as plataformas os arquivos, pastas, histórico de versões e informações de usuários. É claro que algumas informações não são compatíveis entre o VSS e o TFS e não serão transportadas. Abaixo, veremos um overview de uma preparação de migração e falaremos de mais detalhes.

Para que possamos continuar com o assunto, é importante ter instalado as ferramentas abaixo na máquina em que você pretende rodar a ferramenta de conversão:

• Team Explorer
• Permissão de administrador na máquina
• SQL Server Express
• Visual Source Safe 2005 ou superior
• A base do VSS que você quer analisar. O formato da base deve ser 6.0 ou superior. Você deve rodar o conversor na mesma máquina em que se encontra sua base.
• Você precisa também da senha de administrador da base do VSS.

Preparando a base do VSS

Antes de começarmos…

- Peça a todos os usuários para fazer check-ins em seus arquivos
- Crie um backup da base que vai migrar
- Use a ferramenta de análise do VSS para localizar e resolver problemas de integridade de dados na sua base.

Analisando os projetos…

VSSConverter.exe é um utilitário de linhas de comando que precisa dos seguintes parâmetros:

• Um caminho para a pasta que contém o arquivo srcsafe.ini da base que está migrando
• Um arquivo XML que contém configurações
• VSSConverter está em [raiz]:\Arquivos de Programas\Microsoft Visual Studio 9.0\Common7\IDE\ e pode ser chamada através do utilitário de linha de comando do Visual Studio.

Vamos imaginar que sua base do VSS esteja em C:\VSSDB.

Depois que você decidiu que projetos da base vai analisar, é preciso criar um arquivo que contenha as configurações. Este arquivo é a lista de projetos que você quer migrar.

Para criar o arquivo de configurações…

• Vamos criar um diretório para trabalhar com nosso arquivos. Eu criei o C:\VSS2TFS
• Dentro dele, crie o arquivo settings.xml e abra-o com o Notepad.
• Copie o XML abaixo e cole dentro do arquivo, onde $\PastaA e$\PastaB são os projetos que quer migrar.

<?xml version=”1.0″ encoding=”utf-8″?>
<SourceControlConverter>
<ConverterSpecificSetting>
<Source name=”VSS”>
<VSSDatabase name=”C:\VSSDB”></VSSDatabase>
</Source>
<ProjectMap>
<Project Source=”$\PastaA”></Project>
<Project Source=”$\PastaB”></Project>
</ProjectMap>
</ConverterSpecificSetting>
<Settings>
<Output file=”Analysis.xml”></Output>
</Settings>
</SourceControlConverter>

* Para migrar o banco inteiro, use: <Project Source=”$/”></Project>.

• Em <VSSDatabase name, coloque o caminho do diretório onde está sua base do VSS a ser migrada.
• Salve e feche.

O próximo passo será rodar o conversor usando o caminho deste arquivo como parâmetro. O usuário logado no windows precisa ser administrador no SQL Express também. Por padrão, o usuário que instalou o SQL ou o Visual Studio que ele acompanhou já tem essa permissão.

Para analisar o projeto com o conversor…

• No prompt de comando do Visual Studio, digite: VSSConverter Analyze settings.xml
• Quando for solicitado, digite a senha de administrador da base do VSS.

O conversor irá mostrar o status da análise. Quando terminar, irá gerar um relatório (VSSAnalysisReport.xml) e um arquivo de mapeamento de usuários (usermap.xml) e vai salvá-los no diretório corrente.

O próximo passo, depois de ver que a migração terá sucesso fazendo a análise, será fazer efetivamente a migração, o que veremos no próximo post.

Um abraço

Ricardo Serradas