No post anterior, falamos de uma customização de work items usando os recursos do próprio Visual Studio somados aos do Team Foundation Server Power Tools. O que faremos seguindo esse guia é ir além, codificando nosso próprio controle para um formulário de work item.

Vamos relembrar o problema que vamos resolver: precisamos de um campo que vai exibir o andamento geral da atividade, baseado no andamento das 3 etapas, consolidando-as. Para mais detalhes, você pode ler mais sobre o problema proposto na Parte 1.

Para acompanhar, todo o código conte e XML de definição do Work Item “Task” está disponível para download neste link.

Como funciona o deploy de novos controles para Work Items?

Diferentemente do que muitos me supõe, os assemblies de controles customizados para work items não ficam dispostos no servidor do TFS, mas sim em uma pasta específica em cada máquina cliente. Essa pasta é:

[Drive]:\programdata\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\10.0

Por conta disso, precisamos escolher uma forma para distribuir nosso assembly do controle. Isso fica a seu critério. Você pode disponibilizá-la para cópia num compartilhamento na rede, distribuir via pendrive, SkyDrive, etc… Eu escolhi criar um setup que já faz a cópia da DLL para o diretório correto, e aí sim compartilhei este na rede, porém, não vamos entrar nesse mérito.

Vale lembrar que depois do deploy da DLL feito nessa pasta, é necessário reiniciar o Visual Studio para que ele faça sua leitura.

Vamos ao que interessa

Para criarmos nosso controle, criamos um Class Library simples dentro do nosso Visual Studio. Vamos chamá-lo de CustomWorkItemFields. Chamei assim porque, dentro desse mesmo assembly, podemos criar outros novos controles.

Dentro dele, adicionamos um User Control, que vou chamar de “PercentComplete”. Adicionamos então um TextBox simples, o qual vamos chamar de “txtValue”. O último passo dessa parte visual é ajustar o form para que ele fique do mesmo tamanho que nosso TextBox, assim:

Agora, precisamos implementar a inteligência desse controle. Para isso, vamos ao código.

Antes de tudo, precisamos adicionar duas referências ao nosso projeto, que são:

• Microsoft.TeamFoundation.WorkItemTracking.Client, parte do Team Foundation Server SDK
• Microsoft.TeamFoundation.WorkItemTracking.Controls, localizado no diretório:

[Drive]:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies

Feito isso:

-          Faça as referências a esses namespaces no codebehind do controle;

-          Implemente a interface IWorkItemControl;

-          (Opcional, como implementei) crie um struct para organizar os nomes dos campos de work items com os quais vamos trabalhar os cálculos;

-          Crie o método SetPercenteCompleteField() para concentrar a inteligência de cálculo.

O segredo todo desta customização está no evento FieldChanged do WorkItem, porque a cada vez que um campo for modificado e este for um dos 3 novos campos que adicionamos ao formulário, temos que realizar o cálculo e exibir o resultado no nosso controle customizado. Veja como ficou o núcleo da nossa customização, o método “SetPercentCompleteField”:

private void SetPercentCompleteField()
{

try

{

// Obtém todos os valores que estão informados nos nossos campos de acompanhamento

var analysis = int.Parse(_workItemDataSource.Fields[WorkItemFields.Analysis].Value.ToString().Replace("%", string.Empty));

var development = int.Parse(_workItemDataSource.Fields[WorkItemFields.Development].Value.ToString().Replace("%", string.Empty));

var tests = int.Parse(_workItemDataSource.Fields[WorkItemFields.Tests].Value.ToString().Replace("%", string.Empty));

// Aplica os pesos a cada um dos valores e depois obtém porcentagem

var result = analysis*40;

result += development*30;

result += tests*30;

result = result/100;

// Atribui o resultado ao nosso campo de work item para armazenamento na base de dados

_workItemDataSource.Fields[WorkItemFields.PercentComplete].Value = result;

// Atribui esse resultado, formatado com o caractér '%', no campo do controle

txtValue.Text = result + "%";

}

catch (Exception)

{

if (_workItemDataSource == null) return;

_workItemDataSource.Fields[WorkItemFields.PercentComplete].Value = 0;

txtValue.Text = "0%";

}
}

Depois do controle codificado, precisamos agora criar um arquivo de definição do controle de work item, que será colocado na mesma pasta de deploy que informei acima. Veja o seu formato:

<?xml version="1.0"?>
<CustomControl xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Assembly>ALMTeam.BlogSampleCMMi.CustomWorkItemFields.dll</Assembly>
<FullClassName>ALMTeam.BlogSampleCMMi.CustomWorkItemFields.PercentComplete</FullClassName>
</CustomControl>

Formato simples, não? Dentro da tag “Assembly”, informamos qual o nome da DLL onde está localizado nosso controle e, em “FullClassName” o nome completo, incluindo namespace, da classe que o define.

Por último, abrimos o Work Item Type “Task” e criamos o campo BlogSampleCMMi.Tracking.PercentComplete (Integer) para armazenar os dados que nosso controle vai exibir.

Feito isso, fazemos o deploy dos dois arquivos na nossa referida pasta e depois reiniciamos o Visual Studio. A partir de então, um novo tipo de controle ficará disponível para inserirmos no layout do work item. É com ele que vamos criar o campo percent complete no formulário, assim como criamos os outros 3 campos, com a seguinte diferença:

Veja que em “Type”, temos nosso tipo de controle customizado disponível. Não podemos nos esquecer, porém, que devemos também referenciar nosso campo de work item (criado na aba “Fields”) na propriedade “Field Name”.

Depois de criado o controle, salve o seu work item type e veja o resultado criando um novo work item do tipo “Task”:

Perceba que cada vez que um desses 3 campos tem seu valor alterado, o cálculo no campo “Andamento Geral” acontece automaticamente.

Importante: a implementação de um controle customizado para formulários de work items na web (Team Foundation Web Access) é diferente. Logo, verá que esse controle não é visível nos formulários web. Este assunto será abordado num outro post.

É isso galera! No próximo episódio dessa “saga”, veremos como integrar tudo isso à um cronograma do Project.

[]’s

Ricardo Serradas

Há alguns dias atrás passei por uma série de situações curiosas, com algumas diferentes customizações de um template de processo MSF for CMMi 5.0 do TFS para um time de desenvolvimento, situações essas que são relativamente simples, mas achei que caberiam bem em alguns posts sobre como realizar cada etapa. Minha proposta então é expor o problema e depois, numa série de posts, mostrar como é possível implementar tudo isso. Vamos lá.

- Há a necessidade de customizar o template do work item do tipo Task, com 3 campos que compunham o andamento de cada etapa da atividade. Algo parecido com o seguinte:

 Então, os campos “Original estimate”, “Remaining work” e “Completed work” seriam inutilizados a pedido da própria gestão.

- O próximo passo é criar um campo abaixo que mostrasse o andamento geral da atividade, uma porcentagem consolidada, levando em consideração os pesos de cada etapa. Exemplo, se:

 Logo, o andamento geral da atividade é 55%, porque ((100*40)+(50*30)+(0*30))/100 = 55, certo?

Porém, como fazer isso apenas com as regras de campos de work items do TFS? Bingo! Não é possível. Para conseguirmos isso, precisamos criar um controle customizado para nossos work items com essa inteligência embutida.

- Depois disso, sabemos que esses work items serão mapeados para um cronograma no MS Project. A necessidade do gestor é que esse campo com o andamento geral da atividade fosse refletido no campo “% Complete” do cronograma.

- Por fim, é interessante conseguirmos elaborar relatórios a partir desses novos dados. Vamos então criar um novo tipo de Report e publicá-lo na área de relatórios do Team Project.

Vamos resolver esses “puzzles”?

Parte 1: Criar campos customizados para o formulário de work item

Antes de tudo, precisamos ter um um Team Project configurado com MSF for CMMi 5.0 para podermos trabalhar. Recomendo fortemente que crie um Team Project exclusivo para exercícios como esse.

Existem duas formas para customizar um tipo de work item: editando suas definições via XML ou usando o Process Editor integrado no Visual Studio, módulo contido no Team Foundation Power Tools, que pode ser obtido neste link. Mesmo que queira mexer direto no XML, é muito importante baixar e instalar essa ferramenta para que possa ter fácil acesso ao XML definition do work item.

Depois de instalado, vamos primeiro dar uma olhada no XML definition do Work Item do tipo Task. Para isso, dentro do Visual Studio, siga os passos:

Menu Tools -> Process Editor -> Work Item Types -> Export WIT.

Uma janela como essa sera aberta:

Selecione o tipo “Task” do seu Team Project e clique em OK. Agora, você verá uma caixa de diálogo de “Salvar como”, pedindo para escolher o local para salvar o arquivo XML.

Depois de salvo, abra este arquivo com seu editor de textos preferido. Verás um arquivo de cerca de 550 linhas. Vamos falar rapidamente sobre algumas tags importantes desse arquivo:

WORKITEMTYPE – Raiz do tipo do work item. É onde, por exemplo, o nome do tipo do work item é definido.

FIELDS – Aqui são definidos os campos usados no formulário do work item. Aqui algumas propriedades são definidas, como nome do campo, tipo de dado e formato no relatório.

WORKFLOW – Neste trecho é definido o ciclo de vida do tipo de work item. Transições entre estados, campos a serem preenchidos nelas, entre outras coisas são definidos aqui.

FORM – Aqui é definida a aparência do formulário do work item. Posições de campos, tamanho, label, agrupamento, etc.

Mas, há uma frase que acho muito valiosa que Ramon Durães costuma usar, que é “Não tem que ser difícil”. Seguindo essa linha, nós vamos basear nosso trabalho em cima do Process Editor do TF Power Tools.

Vamos então abrir o mesmo arquivo XML numa interface amigável dentro do Visual Studio. Para isso, siga esse caminho: Menu Tools -> Process Editor -> Work Item Types -> Open Work Items From File. Uma janela de abertura de arquivo vai aparecer, selecione o arquivo XML que visualizávamos no editor de texto. Verás então uma janela como essa:

As abas representam os nós daquele XML que falamos acima. Para executarmos a nossa primeira tarefa, precisamos seguir o seguinte roteiro nessa janela:

- Etapa 1: Criar a definição dos campos na aba “Fields” (seus nomes, tipos e descrição).

                Usando o botão “New”, a seguinte janela aparecerá:

Entendendo esse formulário:

Aba “Field Definition”

Name – Simplesmente o nome do campo, não interfere no funcionamento.

Type – Como o nome já diz, o tipo de dado que o campo vai suportar.

Reference Name – É através desse nome que ele será usado tanto no formulário quanto nos relatórios. Tem como padrão ter um nome semelhante ao namespace+nome de uma classe. No nosso exemplo usamos “BlogSamplesCMMi.Tracking.Analisys”.

Help Text – Texto que serve para tooltips, descriptions, etc.

Reportable – Se você pretende usar a informação desse campo em relatórios, é importante escolher um dos valores para esse campo. Os valores podem ser:

                None: Não será inserido no banco de dados relacional (não poderá ser usado em relatórios);

                Dimension: Use este tipo apenas para Integer, Double, String ou DateTime. Os dados nesse campo entram no banco de dados relacional e no cubo como um atributo de dimensão do Work Item para que os dados sejam usados para filtrar relatórios. Use-o para campos que têm uma lista de valores válidos. Work Item Type e State são bons exemplos de uso desta opção.

                Detail: Use esse tipo somente para Integer, Double, String ou DateTime. Os dados nesse campo entram no banco de dados relacional nas tabelas “Work Item History” e “Current Work Item”, mas não no cubo. Esta é uma boa escolha para campos de texto sem restrição, no entanto, você terá que usar a base relacional em vez do cubo. “Summary”, um campo String que contém uma breve descrição de um work item, é um bom exemplo de campo que deve ser do tipo Detail quando usado em relatórios.

                Measure: Use este tipo somente para campos Integer ou Double. São usados para propósitos estatísticos ou para medir certos aspectos do projeto. Cada campo desse tipo aparecer tanto no grupo de medidas “Current Work Item” quanto “Work Item History”. “Estimated Work” é um bom exemplo de campo do tipo Measure.

                Apesar do campo “Formula” existir nesse form com diversas opções, os campos desse tipo são sempre agregadas como Soma (Sum).

Vamos repetir o uso desse formulário para nossos 3 campos, que nomearei assim:

• BlogSampleCMMi.Tracking.Analysis
• BlogSampleCMMi.Tracking.Development
• BlogSampleCMMi.Tracking.Tests

Aba “Rules”

Nessa aba são definidas algumas propriedades do seu campo, como valor padrão, valores permitidos, validações. O que vamos configurar em todos esses campos são as seguintes regras:

REQUIRED – O campo não poderá ficar em branco;

ALLOWEDVALUES – Deixaremos esses campos serem preenchidos somente com os valores “0%”, “50%” e “100%”.

DEFAULT – Em um novo Work Item, é o valor inicial do campo. Vamos configurá-lo da seguinte forma:

                From: value

                Value: 0%

- Etapa 2: Inserí-los no formulário do work item, através da aba “Layout”.

Essa etapa, apesar de ter uma interface amigável, não é tão intuitiva quanto arrastar controles para um Windows Form, mas claro, é muito melhor do que fazer isso direto no XML. J

Para usarmos nosso campo, primeiro precisamos escolher onde vamos colocá-lo no nosso formulário. Eu escolhi criar uma nova aba, chamando-a de “Etapas” e lá eu coloco somente os meus campos, para não poluir outras áreas do formulário. Veja a tela de layout do Work Item Type:

Na árvore à esquerda, os elementos do formulário são organizados numa estrutura de árvore e, à direita, as propriedades do elemento selecionado.

Nessa árvore, existem alguns tipos de elemento. Vamos entendê-los já praticando.

Dentro do TabGroup, criaremos um novo elemento do tipo “TabPage”. Para isso, botão direito em cima do item TabGroup -> New Tab Page. Um novo item na árvore aparecerá. Do lado direito, uma das propriedades chama-se “Name”. Altere-a para “Etapas”.

Para que os controles não fiquem espalhados dentro da aba, criamos um elemento do tipo “Group” para inserir os controles dentro. Insira então um “Group” ao TabPage usando o menu de contexto já usado acima. Quando um Group é criado, um item do tipo Column é criado dentro dele automaticamente.

Agora já podemos inserir nossos controles dentro da aba. Para isso, use o “New Control” dentro do menu de contexto em cima do item “Column”. Um novo item aparecerá como filho da Column. Ao lado direito, algumas propriedades chave do controle precisam ser modificadas. Vamos à elas:

FieldName: É aqui que você deve encontrar a Reference Name do campo que quer inserir. Neste primeiro caso, procuramos por “BlogSampleCMMi.Tracking.Analysis”.

Label: O label para o campo no formulário. Vamos usar “Análise e documentação (peso: 40%):”

Fazemos isso para os nossos 3 campos. Você pode visualizar préviamente como está ficando seu formulário, através do botão “Preview Form”, mas já adianto que não funciona muito bem. Por algum motivo, o que ele mostra não é exatamente como vai ficar seu formulário. L

Depois de pronto, salvamos o arquivo. Precisamos agora importá-lo devolta para o TFS. Para isso, vá ao menu Tools -> Process Editor – > Work Item Types -> Import WIT. Em “File”, localize o arquivo que você editou e em “Project to Import to” selecione o Team Project para o qual a customização se aplicará. Clique então em OK. Aguarde até que a importação seja concluída.

É importante agora dar um refresh no seu Team Explorer para que os templates sejam recarregados. Após isso, abra o formulário de criação de nova task e já verá a nova aba e os campos dentro dela, assim:

Primeira etapa completa! Logo mais, o segundo post falando sobre a criação de controle customizado.

[]’s

Ricardo Serradas

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

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

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

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

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

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

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

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